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

This is only part of a thread. view whole thread
  105101
April 5, 2019 09:00 michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
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
  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
  105176
April 9, 2019 14:09 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :
> So we're talking about providing incomplete feature now, right?
As I understand it, the point is to make unpacking available to arrays, to be consistent with function calls. // This is already supported $result = someFunction($a, $b, ...$array); $result = new someClass($a, $b, ...$array); // This is not $result = array($a, $b, ...$array); So when building an object I can unpack, but not when building an array, why? So the feature is designed to work the same way as for function parameters, which is why string keys are not supported, because they are not supported by the "..." operator for functions. In the end, I see that as making a feature more complete, as the "..." operator which only supported functions will now support array constructors as well. Côme