Hey Rob, Thanks for the feedback.
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. That makes total sense. For sure, we don't want to create two different models or impact the generics design. 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. > 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. Yeah, I was divided when writing the RFC if I should include this or not, but I agree that making them invariant would be much easier/simpler to approach and I'm totally fine if we want to move in this direction. 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. That makes total sense, I can update the RFC in this direction. 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: > 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. Yeah, since I didn't start implementation yet, this was a big concern from my side regarding performance. I agree that waiting to see how the generics design will approach this could be better. 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. Yeah, I think that we have two paths from here: 1. Doing only Implementation Level 1 for this RFC, it's simple enough to be on PHP 8.7 IMO, and then deferring Level 2 and 3 to a new RFC after the generics design. 2. Defer the whole RFC after the generics design and aim for Implementation Level 2 or 3 (3 as preferred one). I'm ok with both paths here. Whatever you think would be better. *---* *Best Regards,* *Wendell Adriel.* *Software Engineer & Architect* *https://wendelladriel.com <https://wendelladriel.com>*
