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.
From: MichaÅ Brzuchalski <email@example.com>
Sent: Friday, April 5, 2019 5:01 PM
To: Rowan Collins firstname.lastname@example.org>
Cc: PHP internals <email@example.com>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
pt., 5 kwi 2019 o 10:50 Rowan Collins firstname.lastname@example.org> 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,