7.1.16 CanonicalNumericIndexString ( argument )
Follow-up from bug 2049.
It should be considered to further restrict canonical numeric indices to positive (?), integer values up to `Number.MAX_SAFE_INTEGER`. I don't see any value in treating "NaN", "Infinity", "-Infinity", "1e+21", "1e-10", "0.1", "9999999999999998" etc. as canonical numeric indices, whereas "+Infinity", "1e21", "1e+20", "1e-6", "0.10", "9999999999999999" are not accepted as numeric indices for integer indexed objects. Implementors will likely prefer a simple definition for integer indexed property keys which avoids performing the ToString+ToNumber combo.
The problem is that at most usage sites there are three alternative code paths:
one for strings that are not CanonicalNumericIndesString
one for strings that are CanonicalNumericIndexString and are valid indexes
one for strings that are CanonicalNumericIndexString but aren't valid indexes
With some refactoring that I probably I could probably avoid the ToString+ToNumber combo for for some of the third case. But I'm probably not going to do it for this edition.
Implementers are are certainly free for each usage to figure out if those when they can avoid those conversions.
(In reply to Allen Wirfs-Brock from comment #1)
> With some refactoring that I probably I could probably avoid the
> ToString+ToNumber combo for for some of the third case. But I'm probably not
> going to do it for this edition.
>
> Implementers are are certainly free for each usage to figure out if those
> when they can avoid those conversions.
In that case just resolve this report as Won't fix?