pon., 20 lip 2026, 17:22 użytkownik Larry Garfield <[email protected]>
napisał:
> On Fri, Jul 17, 2026, at 6:28 AM, Rob Landers wrote:
> > On Fri, Jul 17, 2026, at 12:41, Wendell Adriel wrote:
>
> > 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
>
> I am opposed to this RFC, for all the reasons Rob mentioned. Moreover, I
> don't believe the issues can be resolved by just waiting for the reified
> generics RFC (which I really hope passes). The core issue is that PHP
> arrays are an over-broad data structure, and we need to have a hard,
> type-based (not just implied by generics) distinction between
> lists/sequences, sets, and dictionaries/maps, the same way most languages
> do.
>
> There are a few ways that could be done: 3 generic objects (a la Kotlin,
> my preferred approach), 3 generic objects with extension functions
> (assuming we can get those), 3 new core data types with extension functions
> (very hard to implement as I understand it), etc.
>
I suspect the 3rd option implementation challenge may not be as prohibitive
as it first appears. The design space seems larger than just "extend
arrays" versus "generic objects". I'm still exploring it though, so I'd
rather not jump to conclusions yet.
Cheers,
Michał Marcin Brzuchalski
>
