Re: Re: On arrays starting with a negative index
| From: | Pedro Magalhães | Date: | Thu, 02 Mar 2017 23:10:50 +0000 |
| Subject: | Re: Re: On arrays starting with a negative index | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98389@lists.php.net to get a copy of this message | ||
Hi Rowan,
On Thu, Mar 2, 2017 at 11:39 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:
>
> 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?
>
It would indeed. Internally, nNextFreeElement is initialized with 0 and
updates on larger values. In the PR (
https://github.com/php/php-src/pull/2383/files#diff-fd78a0a3f78ea28c6907f907f25b908eR798
) I'm allowing it to be set to a negative value if it is the first element.
> 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.
With this PR all of your examples would behave consistently but with the
negative indexes.
> 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).
>
The "but at least 0" is exactly what this PR would change.
> 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.
I completely agree on the impact of this change. But I also believe that
this behaviour would be preferable.
Thank you for the feedback.
Regards,
Pedro