RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

This is only part of a thread. view whole thread
  105103
April 5, 2019 09:09 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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 <michal@brzuchalski.com> 
Sent: Friday, April 5, 2019 5:01 PM
To: Rowan Collins collins@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 collins@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