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