On 30 Jul, 2014, at 1:48 pm, Andrea Faulds <a...@ajf.me> wrote: > > >> On July 30, 2014 at 6:01 AM Tjerk Meesters <tjerk.meest...@gmail.com> wrote: >> >> >> Instead of doing that, why not simply disallow negative array indices to be >> used as integers? >> >> In other words, negative indices are treated as if you had used strings so >> that it doesn't upset the the last numeric index kept in the array >> structure. >> >> From what I can tell, it should be a pretty simply patch. >> >> Thoughts? > > That would make sense, but doesn't solve all edge cases as your maximum array > index is still more than 2 times the largest positive integer on 32-bit.
Is that by design, a bug or something else entirely? Could you explain this edge case with some code? > > Perhaps we should completely change behaviour and forbid negative indices and > store indexes that are too large as strings? That would be the sanest way to > go > IMO, solves all the edge cases, and makes ["999999999999999999999999999"] and > [999999999999999999999999999] consistent, resolving that long-existing > discrepancy. Forbidding negative indices is a bit harsh and imho quite unnecessary; turning “out of range” indices into strings should work just fine afaict. Is there a reason why it shouldn’t? A compromise could be to allow string keys that would otherwise have converted into a negative integer, but disallow negative int/float explicitly. > -- > Andrea Faulds -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php