If we didn't provide support for string keys, we can add it back later. If we provide this feature, and later we passed named argument with a different way to handle string keys, then it will be a huge inconsistent and difficult to fix.
Thanks, CHU Zhaowei -----Original Message----- From: Michał Brzuchalski <mic...@brzuchalski.com> Sent: Friday, April 5, 2019 5:01 PM To: Rowan Collins <rowan.coll...@gmail.com> Cc: PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 pt., 5 kwi 2019 o 10:50 Rowan Collins <rowan.coll...@gmail.com> napisał(a): > > The original draft discussed this, but there wasn't agreement on how > identical keys should be handled, e.g.: > > $a = ['foo' => 1, ...['foo' => 2]] > > Should $['foo'] be 1 or 2? Cases were made for both, and it was > pointed out that if we get named arguments, the argument spread > operator will need to work the same way as whatever is decided for arrays. > > So the current approach is to get integer keys working first, using > the same behaviour as for parameters, and then revisit string keys later. > So we're talking about providing incomplete feature now, right? I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1 But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
