> On Jun 26, 2024, at 1:50 PM, Morgan <weedpac...@varteg.nz> wrote:
> So the issue has nothing to do with this hypothetical infinity of > unobservable nulls, and comes entirely down to the fact that with this > pattern a variable may pass > a) because it does not have a key named 'foo', or > b) because it has a key named 'foo' with a string value. Existing array shape implementations already distinguish optional and nullable, I can’t imagine a pattern syntax that doesn’t do that too, It’s just the case of binding with optional keys that seems to be a special case that means the type of whatever you So, possibly inventing a novel binding syntax here because I haven’t followed the syntax discussion and I don’t see bindings in array shapes in the RFC: [‘foo’ => $x is ?string] // just fine, $x is explicitly string|null [?‘foo’ => $x is ?string] // also fine, $x is explicitly string|null [?‘foo’ => $x is string] // $x is actually string|null There’s a precedent with function parameters: function foo(string $bar = null) // $bar is string|null There’s some difference though [] is [?’foo’ => $x is string] // matches, $x === null [‘foo’ => null] is [?’foo’ => $x is string] // match fails And sorry if my sample syntax is weird and ambiguous. I learned in the 90’s that it depends on what your definition of ‘is’ is ;) Cheers, chuck
