On Tue, Jul 21, 2026, at 4:12 AM, Wendell Adriel wrote: > Hey Larry, > >> 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. >> But tacking it onto the already-dangerously-overloaded array mega-type is >> the wrong approach. > > Thanks for the feedback. > I understand the concern of adding more things to the array type and I > think it's a valid concern. > > Would you think that an RFC adding new types, maybe using Kotlin as a > reference (as you mentioned), for having strongly typed array/list > structures would be a better fit? > I'd be happy to propose and work on this if this would be a better > direction/approach.
The challenge with new base types, AIUI, is that the way the engine works right now adding more types is really really hard. Building on top of objects is vastly easier. That's the biggest reason Enums were objects rather than their own base type. (There were other advantages to that approach, too, but implementation potential was a big one.) Base types would likely resolve the "value object" problem for lists: They would (I think) naturally pass like arrays, not like objects. However, it's fairly clear that we want to have methods on collection objects, not just free-floating functions, so if they're implemented as their own types then we would *need* to have extension functions for them to support a more robust standard library for them. If implemented as objects, we could use built-in methods or extension functions, but then we have to deal with the passing semantics problem. And in either case, we really, really want to have operator support. I did some research on this topic a while back with Derick. My conclusion at the time was that we needed generics first, but once that was in then it was pretty straightforward, and by the end I had a clear-ish picture of the API I wanted. (Ignore the one-off syntax; we were considering that initially but decided to hold off and see if real generics were possible.) https://github.com/Crell/php-rfcs/blob/master/collections/research-notes.md (It's rather stream of consciousness, rather than a formal summary, so could flop around a bit.) At this point, I think the best approach is to wait for reified generics and cross our fingers that it finally happens, then loop back and form a working group to decide on which way forward we want to take. The fate of extension functions would also impact the route taken here. --Larry Garfield
