On Fri, Jul 17, 2026, at 12:41, Wendell Adriel wrote:
There are some problems here:
- You have limited K to int or string, but none of these types can be subtyped. As a result K1<:K2 never applies. We can only have K1:=K2.
- You also claim that V is covariant. However, this holds true only for read-only arrays. Write operations of an array use V in contra-variant positions.
I am afraid that we cannot have sound covariant subtyping of an array, unless we clearly separate the read interface from the write one.
Hello there,
Lazare, once again, thanks for the feedback:
I just published a v0.2 of the RFC with changes based on your feedback if you want to take a look at it.
Also, for other members of Internals, I’d be happy to get your feedback on this.
I plan to start implementation as soon as we agree on an Implementation Level I should aim for.
Thanks in advance.
—
Best Regards,
Wendell Adriel.
Software Engineer & Architect
https://wendelladriel.com
Em qui., 16 de jul. de 2026 às 15:18, Wendell Adriel <wendelladriel.ti@gmail.com> escreveu:
There are some problems here:
- You have limited K to int or string, but none of these types can be subtyped. As a result K1<:K2 never applies. We can only have K1:=K2.
- You also claim that V is covariant. However, this holds true only for read-only arrays. Write operations of an array use V in contra-variant positions.
I am afraid that we cannot have sound covariant subtyping of an array, unless we clearly separate the read interface from the write one.
Hey Lazare,
Thank you for the feedback.
I’m going to analyze this and update the RFC document accordingly ASAP.
—
Best Regards,
Wendell Adriel.
Software Engineer & Architect
https://wendelladriel.com
Hi Wendell,
Thanks for updating the RFC.
My largest concern is that this proposal substantially overlaps with the reified generics RFC, which is being held until after the current code freeze in late August or early September at the earliest.
In particular, both proposals need to answer many of the same questions around parameterized types, variance, Reflection, runtime enforcement, inference, and type identity. I think we should avoid committing PHP to a separate set of array-specific rules before the broader generics proposal has been discussed. Otherwise, we risk either constraining the generics design or ending up with two parameterization models that behave differently.
My second concern is the proposed variance model. It is extremely complex for a mutable built-in collection. Collections are normally invariant unless their API clearly separates reading from writing. The generics RFC follows that model: generic parameters are invariant by default, and covariance or contravariance is permitted only where their usage can be proven safe.
Here, an array<Dog> is treated as compatible with array<Animal> only at selected by-value boundaries, based on PHP’s copy-on-write separation. It then becomes invariant for writable aliases and requires additional rules for shared references.
That does not appear to establish a normal subtype relationship. It establishes context-dependent boundary compatibility whose soundness depends on engine-level array separation and reference behavior. I think that will be challenging for users to understand and difficult for the engine to enforce consistently.
Making parameterized arrays invariant would be substantially simpler:
array<int, Dog> !== array<int, Animal>
If covariance is desirable, I think it should come from a separate read-only collection or interface rather than from mutable arrays.
My third concern is the one-argument syntax:
array<TValue>
This implicitly means:
array<int, TValue>
That is surprising. It is not a general array of values because string keys are rejected, but it is not a list either because the integer keys need not be contiguous or zero-based. I would expect array<TValue> to constrain only the value type, with the key type remaining int|string. A future list<TValue> could express the more restrictive numeric-keyed form.
Lastly, I am concerned about repeated runtime validation. Since ordinary arrays do not retain a trusted element-type identity, an untyped boundary loses any information established by an earlier check:
function foo(array<Bar> $arr): int
{
$acc = 0;
foreach ($arr as $bar) {
$acc += $bar->count;
}
return $acc;
}
function bar(array $arr): int
{
return foo($arr);
}
$arr = get_super_huge_array();
echo bar($arr);
At the call to foo(), PHP must recursively validate the entire array again, even if the same array was previously checked elsewhere. For large or nested arrays, this makes a type declaration potentially introduce an O(n) or recursive O(n) cost at every typed boundary.
This is another reason I think typed arrays should be considered together with the wider generics design. A broader design may be able to provide type identity, inference, specialized collection types, or another mechanism that avoids repeatedly rediscovering the element type by traversing the value.
I would strongly prefer that this RFC wait until the reified generics RFC has been discussed, or at minimum limit itself to syntax and Reflection experimentation without committing to independent variance and runtime semantics.
— Rob