# [RFC] Short Array Variable Shorthand - Thread: https://externals.io/message/132700 - Original archive: https://news-web.php.net/php.internals/132700 - Started by weilin-du@qq.com on 2026-09-29T17:44:07+00:00 - Messages: 12 - RFC: Short Array Variable Shorthand (Under discussion) — https://externals.io/rfc/array_shorthand.md - RFC: Named Arguments (Implemented (PHP 8.0)) — https://externals.io/rfc/named_params.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132700 — weilin-du@qq.com — 2026-09-29T17:44:07+00:00 URL: https://externals.io/message/132700#132700 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. ``` 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 :) Thank you, Weilin Du [1]: https://wiki.php.net/rfc/named_params#shorthand_syntax_for_matching_parameter_and_variable_name --- ## #132701 — weilin-du@qq.com — 2026-09-29T18:36:04+00:00 URL: https://externals.io/message/132700#132701 · In reply to: #132700 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 --- ## #132702 — Alexander Egorov — 2026-09-30T05:50:06+00:00 URL: https://externals.io/message/132700#132702 · In reply to: #132700 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. --- ## #132703 — Sebastian Bergmann — 2026-09-30T06:02:06+00:00 URL: https://externals.io/message/132700#132703 · In reply to: #132700 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 --- ## #132704 — David CARLIER — 2026-09-30T06:16:06+00:00 URL: https://externals.io/message/132700#132704 · In reply to: #132703 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. > > Am 29.09.2026 um 19:44 schrieb Weilin Du: > > […] > > 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 --- ## #132705 — Anton Smirnov — 2026-09-30T06:45:56+00:00 URL: https://externals.io/message/132700#132705 · In reply to: #132700 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 --- ## #132707 — weilin-du@qq.com — 2026-09-30T07:40:38+00:00 URL: https://externals.io/message/132700#132707 · In reply to: #132700 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. Thanks for ideas anyways :) BR, Weilin Du [1]: https://github.com/composer/composer/blob/d25ce76a0624857740fe238e0b63ac09e82bbd8f/src/Composer/Command/RunScriptCommand.php#L181 [2]: https://github.com/laravel/framework/blob/6070a6d7e9804a490b12cb889173fbb926b8e3c8/src/Illuminate/Cache/DatabaseStore.php#L225 [3]: https://github.com/sebastianbergmann/phpunit/blob/027d1eb8cac21f6c9b9427ea9437d61785489fc4/src/TextUI/Configuration/SourceMapper.php#L96 [4]: https://github.com/symfony/http-foundation/blob/1c588354b1d2c94ed588edc33914bbf2978cd3ce/FileBag.php#L116 --- ## #132708 — David CARLIER — 2026-09-30T07:53:22+00:00 URL: https://externals.io/message/132700#132708 · In reply to: #132707 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. > > 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. > > Thanks for ideas anyways :) > > BR, > Weilin Du > > [1]: https://github.com/composer/composer/blob/d25ce76a0624857740fe238e0b63ac09e82bbd8f/src/Composer/Command/RunScriptCommand.php#L181 > [2]: https://github.com/laravel/framework/blob/6070a6d7e9804a490b12cb889173fbb926b8e3c8/src/Illuminate/Cache/DatabaseStore.php#L225 > [3]: https://github.com/sebastianbergmann/phpunit/blob/027d1eb8cac21f6c9b9427ea9437d61785489fc4/src/TextUI/Configuration/SourceMapper.php#L96 > [4]: https://github.com/symfony/http-foundation/blob/1c588354b1d2c94ed588edc33914bbf2978cd3ce/FileBag.php#L116 --- ## #132710 — Lynn — 2026-09-30T08:19:28+00:00 URL: https://externals.io/message/132700#132710 · In reply to: #132701 > 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?). ```php $point = [ => $x, => $y, ]; $user => [ 'id' => 1, => $name, => $email, ]; ``` 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. --- ## #132712 — Christian Schneider — 2026-09-30T12:01:18+00:00 URL: https://externals.io/message/132700#132712 · In reply to: #132700 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. > ``` 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 --- ## #132714 — Rowan Tommins [IMSoP] — 2026-09-30T13:38:26+00:00 URL: https://externals.io/message/132700#132714 · In reply to: #132700 >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] --- ## #132774 — weilin-du@qq.com — 2026-10-02T17:22:32+00:00 URL: https://externals.io/message/132700#132774 · In reply to: #132700 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 ```php $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  ```php [$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