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

Reply via email to