728578 - Experiment with removing ToUint32 coercion of JS array length and indexes

Status: RESOLVED DUPLICATE of bug 924058

(Core :: JavaScript Engine, enhancement)

Description

[Allen Wirfs-Brock]

Since, ES1, JavaScript arrays have applied ToUint32 to array indices and lengths.  This cases negative values between -2^31 and -1 to be treated as positive values in the range 2^31 to 2^32-1. This causes

TC39 would like to change this for ES6 and apply a simpler ToInteger conversion in those array-related places where ToUint32 is now used. That conversion does not wrap negative values into large positive values.

The hypothesis is that there is little or no practical utility in the uint32 conversions for arrays and hence it is likely that such a change will case no web breakage. However, this hypothesis needs to be tested on the actual web before TC39 commits to the change.

The change, in theory, allows larger arrays then are possible today and that might impact low level array representation.  However, to test the "won't break the web" hypothesis support for such length > 2^32-2 arrays isn't actually needed.  

Note that this change applies to basic array property accesses and all of the array methods, even when used with non-array objects.  Also "".split and Function.prototype.apply

Comment 1

[Allen Wirfs-Brock]

(In reply to Allen Wirfs-Brock from comment #0)
> Since, ES1, JavaScript arrays have applied ToUint32 to array indices and
> lengths.  This cases negative values between -2^31 and -1 to be treated as
> positive values in the range 2^31 to 2^32-1. This causes
>

typo, should be:

Since, ES1, JavaScript arrays have applied ToUint32 to array indices and lengths.  This causes negative values between -2^31 and -1 to be treated as positive values in the range 2^31 to 2^32-1.

Comment 2

[Thomas 'PointedEars' Lahn]

While we consider abolishing 32-bit restrictions (good idea), let us consider allowing negative integer indexes as well. I like Python for the simple beauty of its a[-1] notation and would like to see this in ES6 implementations as well. Semantics is there with Array.prototype.slice() already, so this would be consistent with expectations and only consequent. That is,

  a[n] === a[a.length + n] === a.slice(n, 1)

where ToString(ToInteger(n)) === n and ToInteger(n) < 0.

Comment 3

[Thomas 'PointedEars' Lahn]

  a.slice(n)

of course.

Comment 4

[Allen Wirfs-Brock]

(In reply to Thomas 'PointedEars' Lahn from comment #2)
> While we consider abolishing 32-bit restrictions (good idea), let us
> consider allowing negative integer indexes as well. ...

This sounds like a separable feature that should be brought up on es-discuss.  It really doesn't affect the "web breakage" issue that this item is primarily about testing.

Comment 5

[Thomas 'PointedEars' Lahn]

Sorry, I do not have time for es-discuss for another month or so.  Feel free to refer to my suggestion there.

Comment 6

[John-David Dalton]

+1

I can dig replacing the ToUnit32 calls with ToInteger when working with Array lengths.
I haven't been bit by length with negative numbers in real code though I have tested it from time to time for kicks.
In general we don't have to worry about Array(-1) as that throws a range error. It only comes into play when using array-like-objects with methods like `[].forEach.call({ length: -1 }, function(){});`

Currently there is no real utility in attempting negative numbers because working with them will lock up most environments.
I also haven't seen any object literal array-like-object mixed with array methods used in real project/lib code (ignoring my unit tests).

How do we start investigating usage?

Comment 7

[David Mandelin [:dmandelin]]

(In reply to JDD from comment #6)
> 
> How do we start investigating usage?

The simple thing would be to just do it and see what happens. Alternatively, we could try to add some checks that detect when the conversions would give different values and upload the totals to Telemetry. But we wouldn't get to see which pages did it, and we wouldn't know if they actually depend on the old behavior to work correctly. So it's probably best to just do it.

Comment 8

[Andy Wingo [:wingo]]

See bug 924058.

Comment 9

[Jason Orendorff [:jorendorff]]

Duping forward since this has become an ES6 feature.