Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
To: internals@lists.php.net
References: <CAJd4=YYAuN295mu91rVFBGbiw-ZNFegv5bhWHCwX9=fXh_MyOA@mail.gmail.com>
 <CAJd4=YZQ2vd2f_q+RqVLTLhDKGV+gaQsYG+Ncf79JZQ7RWuwcg@mail.gmail.com>
Message-ID: <3d5cfa50-5f5d-5633-99ad-052a6b5ac599@gmail.com>
Date: Thu, 2 Mar 2017 22:39:13 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAJd4=YZQ2vd2f_q+RqVLTLhDKGV+gaQsYG+Ncf79JZQ7RWuwcg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: On arrays starting with a negative index
From: rowan.collins@gmail.com (Rowan Collins)

On 01/03/2017 20:46, Pedro Magalhães wrote:
> As a clarification, the current implementation of the PR affects arrays in
> general, not only array_fill. Any array that starts with a negative index
> would continue from that index instead of 0. Meaning that [-2 => true,
> true, true] would now return [-2 => true, -1 => true, 0 => true] instead of
> [-2 => true, 0 => true, 1 => true].

Hi Pedro,

Would other behaviour also be affected?

For instance:

$foo = [ -2 => true ];
$foo[] = true;
$foo[] = true;
var_dump($foo);

If so, this is a much wider BC break; if not, why not?

Currently, this is completely consistent: https://3v4l.org/hXAsf Indeed, 
I would say this is the missing explanation of why array_fill works the 
way it does.


Presumably, this is why there is a note on the manual page:

> See also theArrays <http://php.net/manual/en/language.types.array.php> section of 
manual for a detailed explanation of negative keys.

Although as pointed out by Andrew Nester, this "detailed explanation" 
doesn't actually seem to exist. This seems to be the closest we get:

> As mentioned above, if no key is specified, the maximum of  the existing integer indices is taken, and the new key will be that 
maximum value plus 1 (but at least 0). If no integer indices exist yet, 
the key will be 0 (zero).

Hidden in that first rambling sentence is the key phrase "but at least 
0"; and the second should really say "If no positive integer indices..." 
[It shouldn't say "exist", either, because as the next paragraph 
explains, it can actually be affected by keys that no longer exist; 
which I'd never actually realised before!]

This deserves to be a full section rather than a note, and much more 
clearly articulated. It might even make sense to split that page into 
sub-pages in some way, but I'm drifting into a different discussion, for 
a different list.


The point right now is that array_fill's behaviour is actually 
consistent with the rest of the language, and while the value of that 
behaviour is questionable, changing it now would be a major decision.


Regards,

-- 
Rowan Collins
[IMSoP]