Re: [RFC] Additional splat operator usage

From: 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/

« previous php.internals (#78682) next »