Re: [RFC] Additional splat operator usage
| From: | Andrea Faulds | Date: | Tue, 04 Nov 2014 20:55:27 +0000 |
| Subject: | Re: [RFC] Additional splat operator usage | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78682@lists.php.net to get a copy of this message | ||
> On 4 Nov 2014, at 18:14, Rowan Collins <rowan.collins@gmail.com> wrote:
>
> On 3 November 2014 22:45:11 GMT, Chris Wright <daverandom@php.net> wrote:
>> Good evening list,
>>
>> I'd like to open discussion a relatively simple and clear-cut RFC,
>> either
>> people will like it or they won't, there isn't a lot more to say here
>> than
>> what's in the RFC so please have a read.
>>
>> https://wiki.php.net/rfc/additional-splat-usage
>
> I like the concept with list-style arrays, but find the behaviour with regards associative
> arrays quite confusing. There's already a difference in behaviour between array_merge and + in
> this regard, and having a third way of writing the same thing isn't great - it would apparently
> be legal to write $foobar = [...$foo, ...$bar]; to simply merge two existing arrays.
>
> If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems
> most natural to use this in a list context, but I can imagine always having to check in the manual.
I don’t think they’d be discarded. The named parameters RFC proposes that named keys be kept by
..., and I’d prefer we do that since it makes more sense anyway: [‘foo’=>’bar] and
[...[’foo’=>’bar’]] should act the same, no?
Also, since arrays don’t discard duplicate keys normally, ... shouldn’t.
--
Andrea Faulds
http://ajf.me/