[RFC] Short Array Variable Shorthand

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

Hi!

$point = [:$x, :$y, :$z]; // ['x' -> $x, 'y' -> $y, 'z' -> $z]

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?

Regards,
Alexandr Egorov.

Am 29.09.2026 um 19:44 schrieb Weilin Du:

Today, I want to announce my second RFC to php 8.7
https://wiki.php.net/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 sorry, but I will vote against this RFC.

--
Sebastian Bergmann https://phpunit.expert

Stay up to date with PHPUnit: https://phpunit.expert/newsletter

Greetings,

$point = [:$x, :$y, :$z]; // ['x' -> $x, 'y' -> $y, 'z' -> $z]

$point = compact('x', 'y', 'z');

is still not deprecated

so is

$x = $y = $z = null;
extract($point, EXTR_IF_EXISTS);

but you probably should use neither.

--
Anton

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 13

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.

Thanks for ideas anyways :)

BR,
Weilin Du

Am 29.09.2026 um 19:44 schrieb Weilin Du weilin-du@qq.com:

Today, I want to announce my second RFC to php 8.7
https://wiki.php.net/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.

We have been using a local patch for this short-hand syntax for many years and are very happy as for our coding style this comes up quite often.

I prefer the original :$foo instead of =$foo even though there is a minor clash with the ternary operator but to be honest I would find
[ $bool ? =$foo : =$bar]
to return either an array with the key 'foo' or 'bar' not useful enough and would rather use
$bool ? [:$foo] : [:$bar]

So you have a +1 from me but I would strongly prefer : instead of =,

• Chris

Hi folks!

Today, I want to announce my second RFC to php 8.7
https://wiki.php.net/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.

You might be interested in Nikita's thoughts on this back when named parameters were added: https://wiki.php.net/rfc/named_params#future_scope

Even if it's only applied to arrays initially, it's useful to consider how the syntax fits with both existing and future features.

Rowan Tommins
[IMSoP]

Hi all,

This week I have gathered several recommendations from various
source concerning this RFC. And finally, I am writing this email to
put all these discussions together and announce some changes
to the RFC. I have taken my time to implement a very beginning draft
on Github, which contains tests of every egde cases I can think of.
However, there may be more. Feel free to review it if you want [1]
By the way, the diff itself to the parser is surprisingly small, which
is good to see.

Let me begin with whitespaces. Whitespaces after : is allowed in this
syntax. That whitespace includes not only " ". It also includes \t\n\r.
To be clear you can also put comments between them.

I am going to go back to use : instead of =. I know this sounds
like I am jumping between choices, but I am still going to do it.
People both on and off the list provide very sensible reasons backing
it, and I hope this justify the change:

Now let's talk about ternary expressions. Last week I rush back to using
= because I thought it crashes with existing syntax, which is ternary
expressions inside a array [$a ? $b : $c]. However, there is no ambiguity
when it comes to parser, because we always search if there is a ? token
before the : token, and if there is, it should be parsed as ternarys, otherwise
it should be parsed as a shorthand. The only difference between is ambiguity
for static analyzers, and arguably for humans. For example

$array = [ $a ? $b
: $c
];

Since whitespaces (including " ", \n, \r, etc) is allowed after : in the shorthand
RFC, there may be some cases that is hard for humen to read. However, the
alternative = has the same problem since it also crashes with 

[$a = $b];
[$a, = $b];
``` 

So they have the same problem. It makes no sense to say `=` is better than `:`
when it comes to ambiguity.

Another down side of `=` is it is close to `=>` for keyed arrays, and `:` is more
distiguishable in this case.

Another point is existing languages. The Raku programming language which
support this shorthand all uses `:` [2] And the perl programming language uses
`=>` for similar feature [3].

Finally, I've tried to raise this topic in different php community. And I got the
vibe of preferring `:` tha `=` when it comes to coding aestheic. Or more plainfully,
taste.

So. I hope these reasons justifies why I switch back to `:`. I hope you treat this
as a decision after considerations.

Now, when I was implementing this feature. I find several new edgecases that I
want to bring to the list.

First if `$object` implements ArrayAccess [4] `[:$name] = $object;` is a valid syntax.
And it reads $object["name"] and give the value to $name. It is same to

['name' => $name] = $object

Second:

$name = 'new';

$a = [...['name' => 'old'], :$name];
// ['name' => 'new']

$b = [:$name, ...['name' => 'later']];
// ['name' => 'later']

Third. There are some limitations when you nest. You CANNOT mix [] with list() when
using this syntax. Though this is same when you dont use the shorthand expression.
(So basically you can't do this anyways)
But it's important to mention since I was surprised when writing test for this RFC.

$record = ['user' => ['name' => 'Ada']];

['user' => [:$name]] = $record; // OK
list('user' => list(:$name)) = $record; // OK
list('user' => [:$name]) = $record; // Error

Fourth. You cannot mix keyed and unkeyed elements. Again this is not unique to
the shorthand syntax. You cannot do this anyways but I want to mention just in case.

[:$name, $age] = $row; // Error

I will put these cases into the RFC. Sorry I didn't catch these in the first place. Please
tell me if you have any questions.

Lastly I want to talk about references. When you create an array with `[:$name]`, it
will not create a new reference to the orginal variable.

$name = 'before';
$array = [:$name];
$name = 'after';

echo $array['name']; // before

When destructing, if the variable is already a reference. It will overwrite the stuff that
reference points to.

$target = 'before';
$name =& $target;

[:$name] = ['name' => 'after'];
echo $target; // after

The RFC text is not updated for now. Because I haven't finished testing the syntax,
but there are all of my thoughts and work in this week. Besides them, I find nothing
new. I hope you find it useful. I'd update the RFC tomorrow according to this email.
If any changes, I will inform. I have no intention to vote any time soon.

I wrote this 4 a.m so there may be mistake. Apologize for the wall of text.

Yours sincerely
Weilin Du

[1]: https://github.com/php/php-src/pull/24034
[2]: https://docs.raku.org/syntax/Colon%20Pair
[3]: https://perldoc.perl.org/perlop#Comma-Operator
[4]: https://www.php.net/manual/en/class.arrayaccess.php