[RFC] [DISCUSSION] Type casting in array destructuring expressions

$handle = fopen('test.csv', 'r');
while (($data = fgetcsv($handle)) !== false) {
[int $id, string $data, int $year] = $data;
// do something with the correctly typed variables
}

The code would trigger a fatal error when strict_types are enabled. With
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=0
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 give
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] = $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] = $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=0);
[int $id, string $data, int $year] = $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=1);
[int $id, string $data, int $year] = $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

I also like Levi's proposal but for the use cases which lead me to the
idea for this proposal where I explicitly want to cast values and don't
check their current types it's difficult to use. I think it serves
different use cases.

My personal pov is that the use case you describe is not sound enough to
require a new syntax; this is still fine and explicit (borrowing from one
of your examples), especially considering the weak points noted by Rowan:
$now = (int) $a[0];
$future = (int) $a[1];

The huge benefit of Levi's proposal is that it works with any types, not
just the castable ones: any class/interface would fit there. This means
this new syntax would provide another "type barrier" that could help the
engine or any type analyzer get a better understanding of the variables at
hand.

You mention the syntax looks weird to you. How would you design the
syntax if you want to cast the values instead of type checking them?

I would abstain from trying to answer then.

I now understand you had this different use case in mind, so I would
totally understand that in turn, you'd be not interested in working towards
Levi's proposal. On the other hand, I would so much like you'd be :)

Cheers,
Nicolas

Le 7 avr. 2020 à 17:09, Enno Woortmann enno.woortmann@web.de a écrit :

As the proposal explicitly aims at type casts
when working with data from a untyped source (eg. iterating over a CSV
file, XML without a XSD defining the types of the elements)

I feel that the RFC lacks a section named “Motivation”...

That said, the larger question is: How many ad-hoc features do we want to add to array destructuring? For type-casting is one specific kind of transformation you may want to apply to your data.

—Claude