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

Am 07.04.2020 um 13:14 schrieb Nicolas Grekas:

Le mar. 7 avr. 2020 à 12:07, Enno Woortmann <enno.woortmann@web.de> a écrit :

Am 25.03.2020 um 18:53 schrieb Enno Woortmann:

Hi, I've written the RFC and implemented a first patch concerning the idea to allow type casting in array destructuring expressions. The RFC is located at https://wiki.php.net/rfc/typecast_array_desctructuring The patch can be found in MR 5296 located at https://github.com/php/php-src/pull/5296 Thanks for further feedback! Cheers, Enno

Hi together, As there has been no recent discussion concerning this RFC (tbh no discussion at all, I don't know if it's like "ok, cool idea, just let's do it" or more like "oh no, let's forget this asap") I'd like to start the voting tomorrow if there are no further comments on this proposal.

On my side, I like the idea but the proposed syntax looks weird. I would vastly prefer (and upvote) Levi's proposal: [int $a] = [123]; // note: no brackets, this is a type declaration, not a casting operation [string $a] = [123]; // TypeError or implicit cast depending on declare(strict_types=1/0) in the file Nicolas

Hi Nicolas, thanks for your comment. 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) an implementation following the type check proposal would force me to write my code into a file with  strict_types=0. As I'm a big fan of strict_types=1, I try to avoid such files (fingers crossed for the namespace scoped declares some day, but then I'd need to move my code to a separate namespace), also see my answer to Rowan @ https://externals.io/message/109305#109354 with different combinations. Maybe, as the type system get's a many improvements lately (eg. typed properties), it's also time to think about a refined type cast system for better control over the casting process (nullable casts already have been a topic, additionally strict casts as suggested by Rowan). 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. 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? Cheers Enno