We also support the foreach syntax ofc, see examples
in the RFC.
Same feature has been implemented in perl. And 13
years ago the named argument RFC have already
list this as part of the future scope [1]
Some may ask why don't you propose this for all
functions but just for the `[]` syntax in arrays? Well,
sadly I don't have enough time and energy to put
in php now (I am unfunded) so I will leave it for others
if they want in the future.
Again I hope you'all find this useful and interesting
To be honest, I'm not a huge fan of quirky and tricky perl-like
syntaxes in languages, but in general I think I personally would like
such a feature for exactly one purpose: to cast DTO's to arrays
if this feature also supported [=$this->id, =$this->name, ...etc] (or
replace $this with any other object). This would allow to constrain
key-names in resulting arrays to reflect exact names of properties of
the class.
But according to your current version of RFC, it is not the case. Is
there any strong reason to not support such behaviour?
I am not convinced by the premise of this RFC: it opens with the claim that associative arrays often repeat a key and a variable with the same name, but it offers no evidence for this, and it does not match my experience.
A syntax change should be backed by data, for instance an analysis of a representative body of real-world code.
Even if the pattern were common, I do not see any benefit in the proposed syntax. It saves a few characters but adds another form that every reader and every tool has to understand.
Hi Weilin,
Adding an usable new feature to array is always challenging.
But even if you were able to back up that this function would be
useful, how expressions such as assignment expressions (e.g. [$x =
$y]) would work well in that context ?
Regards.
On Wed, 30 Sept 2026 at 07:05, Sebastian Bergmann <sebastian@phpunit.de> wrote:
Am 29.09.2026 um 19:44 schrieb Weilin Du:
> Today, I want to announce my second RFC to php 8.7
> PHP: rfc:array_shorthand
>
> This RFC brings a IMO useful syntactic sugar to array's
> construction and destruction. I hope you'all find this
> interesting! To be short:
>
> ```
> $point = [:$x, :$y, :$z]; // ['x' -> $x, 'y' -> $y, 'z' -> $z]
> [:$x, :$y, :$z] = $point; // reverse.
> ```
I am not convinced by the premise of this RFC: it opens with the claim
that associative arrays often repeat a key and a variable with the same
name, but it offers no evidence for this, and it does not match my experience.
A syntax change should be backed by data, for instance an analysis of a
representative body of real-world code.
Even if the pattern were common, I do not see any benefit in the proposed
syntax. It saves a few characters but adds another form that every reader
and every tool has to understand.
I am goiing to reply to the thread with this single email.
Firstly assignment expressions works well in this context.
The first token before `=` of `[$x = $y]` is different to `[$x, =$y]`.
Hence it will never conflict.
Secondly for compact and extract functions. I was aware.
The different is
a. They can't mix the shorthand with explicit keys:
$user = ['id' => 1, =$name, =$age];
b. extract overwrite vars with the same name. But in this context
we can declare the var name to be written
[=$name] = $row
c. They don't work in foreach loop.
Thirdly to prove its usefulness. Well, I'd say this works well with
my experience esp in returning arrays for functions. Because in my
code base, the local var's name could be the same to its key's name
and if some of it don't we just exlicitly state it there.
return ['x' => $point_x, =$y, =$z];
If you want me to prove this pattern in the code base. It's hard to
give out the overall statistics but I can provide some usage in famous
php project I see [1][2][3][4]
Thus, I am not convinced. This feels useful in my experience. But I know
different devs have various taste to pl design and I am one of those perl
fan when it comes to this syntax. And I can see why some may feel bad in
it.
I will leave the DTO stuff after I done the implementation. However, it feels
like I can already withdraw this RFC given the state of current discussion.
Sorry for the confusion, I did not mean a parser conflict. I meant
more that a single missing comma silently turns one valid program into
another:
$b = 5;
$arr = [$a =$b]; // today: assigns 5 to $a, $arr is [0 => 5]
$arr = [$a, =$b]; // with the RFC: $arr is [0 => $a, 'b' => 5]
Cheers.
On Wed, 30 Sept 2026 at 08:43, Weilin Du <weilin-du@qq.com> wrote:
Hi all,
I am goiing to reply to the thread with this single email.
Firstly assignment expressions works well in this context.
The first token before `=` of `[$x = $y]` is different to `[$x, =$y]`.
Hence it will never conflict.
Secondly for compact and extract functions. I was aware.
The different is
a. They can't mix the shorthand with explicit keys:
$user = ['id' => 1, =$name, =$age];
b. extract overwrite vars with the same name. But in this context
we can declare the var name to be written
[=$name] = $row
c. They don't work in foreach loop.
Thirdly to prove its usefulness. Well, I'd say this works well with
my experience esp in returning arrays for functions. Because in my
code base, the local var's name could be the same to its key's name
and if some of it don't we just exlicitly state it there.
return ['x' => $point_x, =$y, =$z];
If you want me to prove this pattern in the code base. It's hard to
give out the overall statistics but I can provide some usage in famous
php project I see [1][2][3][4]
Thus, I am not convinced. This feels useful in my experience. But I know
different devs have various taste to pl design and I am one of those perl
fan when it comes to this syntax. And I can see why some may feel bad in
it.
I will leave the DTO stuff after I done the implementation. However, it feels
like I can already withdraw this RFC given the state of current discussion.
On Tue, Sep 29, 2026 at 8:38 PM Weilin Du <weilin-du@qq.com> wrote:
Hi,
Some amendment have been added after this email.
We are using the = char instead of :
$point = [=$x, =$y];
And we are supporting array() and list() for this RFC now,
so not only .
See the RFC for reasons. Discussions have happened in
the official phpc’s discord server and thanks Tim Düsterhus
for the ideas.
This RFC is still in a very early stage. So there can be vagueness
and obvious issues. If there is, please point out.
Thanks,
Weilin Du
Have you checked if it is possible to use the arrow itself instead? To me this syntax feels more familiar, especially when using multiple lines. Currently this is a syntax error and should be usable (question mark?).
I saw some mentions of compact and extract, I will never use those because they are confusing to read and understand, where as this RFC is explicit in what it does.
