Hi Rob
On Wed, Jun 26, 2024 at 10:36 PM Rob Landers <[email protected]> wrote:
>
>> On Wed, Jun 26, 2024, at 21:50, Morgan 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.
>>
>> In other words, "this key is optional, but if it is defined it must
> match this pattern".
>
> Seriously, write out using it both ways. I asked in the beginning for someone to give a
> realistic example showing a practical difference in the final implementation and I haven’t seen
> one. I will gracefully eat my hat. The main issue is that key-existence-check is logically
> inconsistent with itself (if you say the key shouldn’t exist or be a string, you’d be surprised
> to get null from that key!)
function test($value) {
if ($value is ['foo' => ?string]) {
$foo = $value['foo'];
}
}
test([]);
With your approach, the example above would emit a warning, even
though the context within test() doesn't look like it should. If
?string means that the index might or might not exist, all code that
accesses them must check for existence, even when not needing to
handle null itself. That doesn't seem desirable to me.
I also think the issue goes further. If anything|null means that the
offset might not exist, does that include mixed? That makes ['foo' =>
mixed] essentially useless.
Ilija