Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103458
To: "'Wes'" <netmo.php@gmail.com>
Cc: "'PHP Internals'" <internals@lists.php.net>
Date: Mon, 19 Nov 2018 23:07:44 +0800
Message-ID: <062701d48019$9fe59cf0$dfb0d6d0$@jhdxr.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdSAF/m9hb3ad4TgSOSSHTcFW2yO8g==
Content-Language: en-us
Feedback-ID: Yeas:jhdxr.com:qybgforeign:qybgforeign2
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression
From: me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)


> Hi, I worked together with Chris Wright, author of the other RFC =
covering
> the same thing.

Thanks for pointing it out and also thanks CMB for posting the link.=20
I tried to search for this topic but didn't find anything, as we have =
too many names for this feature.


> The most important thing is that we don't want it work like =
array_merge();
> in other words, it must not cover both lists and maps at the same =
time.

Since PHP array is a mixture of list (traditional array in most of other =
languages) and map (a k=3D>v data structure),=20
any new syntax related to PHP array most cover both use cases.
`...` means unpacking, I think we are all good with this semantic, the =
disagreement is about the behavior of key conflict.

Let's use your example to start my explanation:
```
['a' =3D> 1, 'b'=3D>2, ...['a' =3D> 3]]
```

Since we are create a new syntax with the existing array definition =
syntax, let's try to do the unpack manually.
```
['a' =3D> 1, 'b' =3D>2, 'a' =3D> 3]
```

Although this not a good practice to write such codes, it's still valid =
in current version without any warning or even notice.=20
The answer for above code is
```
['a' =3D> 3, 'b' =3D> 2]
```

It looks weird at first glance, but IMO the more important thing is this =
is how PHP works now.=20
I really don't think it's a good idea to introduce a new way how two =
arrays will get merged.=20
It will confuse developers.



I also notice there is an interesting question in the discussion of your =
RFC.
> So, it's just an operator version of array_merge(), with no advantages
> other than brevity? I'm not sure why it's any more or less applicable =
to
> constant arrays vs variables than + or array_merge() are.

Yes. The spread operator follows the semantics as `array_merge`, but =
besides brevity and better performance=20
(no more overhead of function call, and constant array can be compiled =
at compiled time),=20
this RFC also brings the support for objects implementing =
`Traversables`.

Best regards,
CHU Zhaowei