Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109759
To: internals@lists.php.net
References: <2b8e5da5-2f21-57a2-7e7d-243c686cc69d@web.de>
 <CAF+90c9NmpX9v=YVyNArSVAfvpq5gRR6HPFrUCzVzn-5Wr2zSQ@mail.gmail.com>
Message-ID: <725377f8-f8f2-a681-ee8d-c6124d7f523f@web.de>
Date: Tue, 21 Apr 2020 19:20:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c9NmpX9v=YVyNArSVAfvpq5gRR6HPFrUCzVzn-5Wr2zSQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Type hints in array destructuring expressions
From: enno.woortmann@web.de (Enno Woortmann)


Am 16.04.2020 um 16:50 schrieb Nikita Popov:
> As you say, this syntax will likely run into parsing issues. Once you ta=
ke
> into account that types aren't just "int", but also "Foo|Bar", and also
> consider that we have support for references in unpacking, you could be
> left with something like
>
>      [int|float &$foo] =3D $bar;
>
> Without actually testing, I would expect that this is going to run into
> issues of similar difficulty as the arrow function proposal encountered.
>
> Rather than integrating this into the destructuring assignment syntax, I
> think it would be more helpful to view this as the infallible variant of
> pattern matching, which is also being discussed in the "match expression=
"
> thread. As suggested there, the syntax could be something like
>
>      let [int|float $foo] =3D $bar;
>
> and would throw if the RHS does not satisfy the pattern on the LHS (unli=
ke
> the match variant, which is fallible).
>
> I think this might help to bring things under one umbrella, and to draw =
a
> clearer line between this functionality and typed variables (if it's jus=
t a
> pattern guard, then it's expected that the type restriction is checked
> instantaneous, not enforced persistently.)
>
> Nikita

Hi Nikita,

thanks for your response and your assessment concerning the parser change.

I've played a bit around with the idea and came to the conclusion that
changes like these are far beyond my knowledge of the code base and my C
skills. Consequently I will not continue working on this idea as it
moves away from my initial idea to simply cast values.

If anyone wants to take this RFC draft, feel free to tackle this topic
further. The secondary voting of the "casting in array destructuring
expressions RFC" which will be closed in two days shows some interest
into this topic.

Cheers, Enno