On Fri, Jun 21, 2024 at 7:20 PM Robert Landers <landers.rob...@gmail.com> wrote: > > > I'm always surprised why arrays can't keep track of their internal > > > types. Every time an item is added to the map, just chuck in the type > > > and a count, then if it is removed, decrement the counter, and if > > > zero, remove the type. Thus checking if an array is `array<int>` > > > should be a near O(1) operation. Memory usage might be an issue (a > > > couple bytes per type in the array), but not terrible.... but then > > > again, I've been digging into the type system quite a bit over the > > > last few months. > > > > And every time a modification happens, directly or indirectly, you'll > > have to modify the counts too. Given how much arrays / hash tables are > > used within the PHP codebase, this will eventually add up to a lot of > > overhead. A lot of internal functions that work with arrays will need > > to be audited and updated too. Lots of potential for introducing bugs. > > It's (unfortunately) not a matter of "just" adding some counts. > > Well, of course, nothing in software is "just" anything.
Counters are not cheap as we need one slot for each type in the array so we need a dynamic buffer and an indirection, plus absolutely every mutation needs to update a counter, including writes to references. It is possible to remove the counters and to maintain an optimistic upper bound of the type (computing the type more precisely when type checking fails), but I feel this would not work well with pattern matching. Also, a few things complicate this: - Nested writes like $a[0][0][0]=1 need to backtrack to update the type of all parent arrays after the element is added/updated - Supporting references to properties whose type is a typed array, or dimensions of these properties, is very hard Fixed-type arrays may be easier to support but there are important drawbacks in usability IMHO. This does not play well with CoW semantics. Best Regards, Arnaud
