Hi Rowan, On Thu, Mar 2, 2017 at 11:39 PM, Rowan Collins <rowan.coll...@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
