Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109354
To: internals@lists.php.net
References: <59e48d22-6d2d-19df-1b4a-cb2e7281ceea@web.de>
 <CAAKU0uns+y-7qGq_TCaZEQgcjiR-yjUuAyTU7D4j74eGbLFJ3g@mail.gmail.com>
 <127676cc-c86d-bad9-8501-fbd59975d686@web.de>
 <CALKiJKpCkDFPEYKmDa-4gR+Vz9rXXP4f7wbVcPsn52DDQKN4jQ@mail.gmail.com>
Message-ID: <ad46c0c7-a37b-88c3-4989-a81e2a7493fe@web.de>
Date: Thu, 26 Mar 2020 20:49:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CALKiJKpCkDFPEYKmDa-4gR+Vz9rXXP4f7wbVcPsn52DDQKN4jQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring
 expressions
From: enno.woortmann@web.de (Enno Woortmann)

>> $handle =3D fopen('test.csv', 'r');
>> while (($data =3D fgetcsv($handle)) !=3D=3D false) {
>>       [int $id, string $data, int $year] =3D $data;
>>       // do something with the correctly typed variables
>> }
>>
>> The code would trigger a fatal error when strict_types are enabled. Wit=
h
>> strict_types disabled it would behave identically as the currently
>> proposed casts.
>>
>
> As I mentioned in a previous e-mail, if it followed current strict_types=
=3D0
> semantics, it would error if the input row was something like
> "42,hello,not-a-valid-year".
>
> Following standard cast semantics, that input would instead silently giv=
e
> you a value of 0 in $year, which is often not what you want.


Hi Rowan,

I liked your idea of strict casts which would increase the possibilities
of casting in general but also improve casting while array destructuring.

Let's have a look at various combinations.

The current proposal (behaviour doesn't depend on strict_types):

[(int) $id, (string) $data, (int) $year] =3D $data;

"42,hello,2020" --> Works as expected, everything fine
"42,hello,not-a-valid-year" --> results silently in a 0. May not be
wanted, as you describe, but in my opinion that's fine as it's the
current casting behaviour


Extending the proposal with strict castings (behaviour doesn't depend on
strict_types):

[(!int) $id, (!string) $data, (!int) $year] =3D $data;

"42,hello,2020" --> Works as expected, everything fine as "2020" can be
casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


Using regular type checks (depends on strict_typed):

declare(strict_types=3D0);
[int $id, string $data, int $year] =3D $data;

"42,hello,2020" --> Works as expected, everything fine as the id with
"42" and the year with "2020" can be casted to an int
"42,hello,not-a-valid-year" --> Results in a TypeError as the year can't
be casted to an int


declare(strict_types=3D1);
[int $id, string $data, int $year] =3D $data;

"42,hello,2020" --> Results in a TypeError as id and year are both strings
"42,hello,not-a-valid-year" --> Results in a TypeError as id and year
are both strings

My favourite behaviour would be the one described for strict
castings/regular type checks with strict_types disabled. But I don't
like the idea it's only usable without strict_types to get the
casting-feature intended by the RFC.

Cheers, Enno