Re: [Early Feedback] Pattern matching

From: Date: Mon, 24 Jun 2024 21:17:39 +0000
Subject: Re: [Early Feedback] Pattern matching
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
> On Jun 24, 2024, at 1:53 PM, Robert Landers <[email protected]> wrote:
>
> $arr = ['a' => 'a string'];
> $arr is ['a' => string, ?'b' => $value, ...];
>
> This syntax implies that a non-existent key is a special case, and if
> it passes as-is, it will be. If there is a binding and the key is
> missing, what happens to that binding? Is it left in an undefined
> state or is it assigned NULL? If it is assigned NULL, what is the
> value of checking for non-existence; why not just check for NULL in
> the value? If it is left "undefined", then you still have to handle it
> as though it is a NULL value (perhaps more so because simply trying to
> detect its value may cause the very warning you are trying to avoid --
> and will fatally error in PHP 9:https://3v4l.org/Rbadk.
> see
> https://wiki.php.net/rfc/undefined_variable_error_promotion).
>
> Thus, this "key existence check" is inconsistent with the language and
> possibly redundant, as you'd have to check that resulting value was
> null anyway:
>
> $arr is ['a' => string, 'b' => ?string, ...];
>
> Hope that clarifies things.

I see what you mean: leaving $value undefined would be a high-caliber footgun for sure! I suppose
binding to optional keys could just be verboten, but that kind of restriction would make for a lousy
DX. Distinguishing between “optional and not nullable” and “not optional but nullable” still
seems reasonable for array shapes in general, but optional and nullable pretty much have to become
one once bindings are involved.

So color me convinced :)

Cheers,
chuck


Thread (79 messages)

« previous php.internals (#123792) next »