Re: [RFC] Additional splat operator usage

On 4 November 2014 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. > > It would be legal and I don't see this as a problem? This would be identical to array_merge($foo, $bar) and this is intentional, the proposal is entirely intended to make merging literal constant arrays and variable arrays simpler, it doesn't add yet another set of rules for how the merge will be performed - we really don't need that. If you wanted to discard the keys and turn two associative arrays into a list, you could write $foobar = [...array_values($foo), ...array_values($bar)] (but I don't recommend this). More sensible uses w.r.t. associative array merging might be creating the array to pass to PDOStatement->execute() (this is quite a contrived example, but I have had effectively this use case in more complex code): function execute_statement_with_extra_params(PDOStatement $stmt, array $params) { return $stmt->execute(['param1' => 1, 'param2' => 'value', ...$params]); } I had a similar case recently and was surprised to find that it didn't work (i.e. I find it quite intuitive), which is the main motivation for writing this RFC. > 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. > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >