Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
References: <CAJaRsPtPT0Jtn5MNnMuEO4o79oj1Anw63v1PdKhuVG4CD2qw-g@mail.gmail.com>
 <574AF60A.6070908@nunninger.info>
In-Reply-To: <574AF60A.6070908@nunninger.info>
Date: Sun, 29 May 2016 17:40:26 +0000
Message-ID: <CAJaRsPvjopKKZOhPJtCkQ3JH7sLo5qvBVgLkcSAAMqNVkQqEZg@mail.gmail.com>
To: Thomas Nunninger <thomas@nunninger.info>, PHP Internals <internals@lists.php.net>
Cc: jmikola@gmail.com
Content-Type: multipart/alternative; boundary=001a113de8de31e3750533fea34f
Subject: Re: [PHP-DEV] [RFC Discussion] array_change_keys()
From: colinodell@gmail.com ("Colin O'Dell")

--001a113de8de31e3750533fea34f
Content-Type: text/plain; charset=UTF-8

>
> shouldn't it be possible to return null as new key? That way you say:
> Use the next free integer index.
>
> Not sure if returning null is wanted (as it could hide errors in the
> callback) or needed in some real world use cases. But it would be more
> in sync with $a[] = ...
>

That's an interesting idea, but it would go against how other array
functionality works.

For example, if you ran this:

    var_dump( array_combine([null, null], ['foo', 'bar']) );

You'd get the following output:

array(1) { [""]=> string(3) "bar" }

The null you intended to be a key becomes an empty string instead, and the
latter value of "bar" overrides the former one.

You'll see this same behavior if you did the following:

    $a = [];
    $a[null] = 'foo';
    $a[null] = 'bar';

So that's one way nulls are handled.  The other way is to raise a warning
and skip that element, which is what array_flip (and this proposal) does:

    var_dump( array_flip(['foo' => 'null']) );

Output:

Warning: array_flip(): Can only flip STRING and INTEGER values! in
/in/7bBvO on line 3 array(0) { }

Implementing the feature you mentioned would introduce a third approach,
which is something I'd like to avoid.  Perhaps a future RFC could implement
this feature, either for just this one function or others as well?

Colin

--001a113de8de31e3750533fea34f--