Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.41 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <E336496D-4FEB-4B99-ABA6-AFF0F42E5339@gmail.com>
References: <CAGAGxbY+2G8zOWkHW7t_QhvFSFM=QLY7tSWJpGc8tAgpraLm-w@mail.gmail.com>
	<E336496D-4FEB-4B99-ABA6-AFF0F42E5339@gmail.com>
Date: Wed, 5 Nov 2014 10:24:28 +0000
Message-ID: <CAGAGxbaFVSdtX6JbLPmX+Pg+oJ0mmNuHrrx3EM4q-XDV4JytZQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c14c241ce2b8050719fc22
Subject: Re: [PHP-DEV] [RFC] Additional splat operator usage
From: cw@daverandom.com (Chris Wright)

--001a11c14c241ce2b8050719fc22
Content-Type: text/plain; charset=UTF-8

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
>
>

--001a11c14c241ce2b8050719fc22--