Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109676
To: internals@lists.php.net
Message-ID: <2b8e5da5-2f21-57a2-7e7d-243c686cc69d@web.de>
Date: Thu, 16 Apr 2020 12:20:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Type hints in array destructuring expressions
From: enno.woortmann@web.de (Enno Woortmann)

Hi together,

as the voting for the "Type casting in array destructuring expressions"
shows a clear direction to be declined (sad faces on my side, I really
would've liked it as a feature completion of the casting feature set
without the need for a really new syntax, as the parser also already
coverred it, but ok, time to continue :D ), combined with a strong
interest for the topic "type checks in array destructuring expressions"
(as well in the discussion as in the vote) I've set up a first draft of
an RFC covering this topic:

https://wiki.php.net/rfc/typehint_array_desctructuring

The discussion around the casting in array destructuring brought up the
idea to perform regular type checks in array destructuring expressions.
This RFC proposes a new syntax to type hint a variable inside an array
destructuring expression:

$data =3D [42, 'Example', 2002];
[int $id, string $data, int $year] =3D $data;

The type hints behave identically to the type hints used in method
signatures (compare https://wiki.php.net/rfc/scalar_type_hints_v5). This
especially includes a behaviour depending on the strict_types directive.

Additionally to scalar type hints also object type hints are possible.

I've not yet started an implementation draft but I think this one will
be more tricky than the type cast implementation approach. As the parser
re-uses the array definition for array destructuring expressions (which
also leads to the type cast implementation without touching the parser)
adding type hints to the definition would also affect other parts of the
language eg. something like:

$x =3D [int $a, string $b];

would be parsed by the parser. I'm currently not able to grasp the
impact of such a change. But that's another topic.

Let's focus on the idea itself instead of the implementation first.
Thoughts on the first draft?

Cheers, Enno