> On Jun 26, 2024, at 1:50 PM, Morgan <[email protected]> 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