On Fri, Jul 17, 2026, at 12:41, Wendell Adriel wrote:
>> There are some problems here:
>> 1. 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.
>> 2. 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
> <[email protected]> escreveu:
>>> There are some problems here:
>>> 1. 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.
>>> 2. 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
