On Sat, Jun 22, 2024, at 12:14 PM, Brandon Jackson wrote: >> To clarify here, these all come as a set. Array shapes aren't their own >> "thing", they just fall out naturally from array patterns. So it's not >> possible for associative patterns to conflict with array shapes, as they are >> literally the same thing. :-) I'd have to check with Ilija but I don't >> believe there's much internal difference between list and associative >> patterns. This one isn't on the ADT hot path, so it could be postponed >> >> I see no way for associative array patterns/shapes to conflict with generics >> at all. > > Thanks for the clarification. I was looking at the example given in > the overview trying to figure out the boundaries between array > structure patterns, array shape patterns, and nested patterns. It > sounds like it can be summarized to nested patterns with the option to > add or omit `...` determining if unexpected key/values are allowed. > Also again, just throwing out hypothetical curve balls that could > delay or halt other good parts. At this point I don't actually expect > generics to ever be a thing.
To clarify a bit more: There's really only two slight variations on the same pattern for arrays, list and associative. In both cases, each specified element of the array is matched against its own sub-pattern, recursively. That sub-pattern may be (almost) any other pattern. So this: $arr is ['a' => 'A', 'b' => 'B', 'c' => [int, int, int], 'd' => string] Is entirely valid, and decomposes to: $arr['a'] is 'A' && $arr['b'] is 'B' && $arr['c'][0] is int && $arr['c'][1] is int && $arr['c'][1] is int && $arr['d'] is string (This is why literal patterns are basically non-negotiable. On their own, they're kinda pointless. As a sub-pattern of another pattern, they're mandatory.) Array shapes aren't really a feature per se; they're just a natural fall-out of the recursive syntax. --Larry Garfield
