Re: Re: [Request][Discussion] Double value as array key improvement

On Thu, Aug 31, 2017 at 2:58 AM Andrea Faulds <ajf@ajf.me> wrote: > Hi there, > > Andrew Nester wrote: > > > > > > Hello internals! > > > > I was working on solution for the problem of double to int conversion > for array indices and would like to create an RFC for proposed solution - > emitting warning when integer overflow happens during double to int > conversion. > > > > Does it look like good idea? > > > > Thanks! > > > > It's certainly an improvement over silently truncate-wrapping like at > present. > > But one question I might have is whether there's any benefit to it just > being a warning rather than an Error. Surely nobody would rely on this > behaviour? I can't imagine a use-case where it doing % 2^64 on your > indices is helpful. Who would want the code execution to continue beyond > that point? Will someone want to silence this error? > > Compare how the int type declaration on userland functions > handles > floats like these: it throws a TypeError. Internal functions *do* throw > a warning, but they don't execute their body and return NULL instead > (they do throw a TypeError in strict mode). > > If you threw some kind of Error instead, I can't imagine it causing > backwards-compatibility problems in practice, and at least personally, I > think it would be the better choice. But I wrote the RFC that made > passing floats > PHP_INT_MAX or < PHP_INT_MIN to functions with integer > parameters produce those errors, so of course I'd say that… > > Anyway, thanks for bringing this up! It's something that I've wanted to > fix since a long time ago and had forgotten about. > (Bumping an old discussion here) I think the parallel with how we handle this for int parameters is a good one, and it would make sense to throw a TypeError when trying to use an out of range float key in an array. I'm slightly uneasy about the value-dependent behavior (e.g. your code might start throwing because the user entered a particularly large value somewhere). However, the argument applies to parameter handling in the same way, and as far as I know our behavior there has never proven to be a problem. And as using an out of range value essentially produces a nonsense result (say a negative number though your input was positive), I think pointing out the issue with a TypeError would be a win anyway... Nikita