Ecma262: Redundancy in the `ToLength`?

Created on 27 Oct 2016  Â·  7Comments  Â·  Source: tc39/ecma262

http://www.ecma-international.org/ecma-262/7.0/#sec-tolength

The step 3 there is an explicit comparison with the +Infinity.

What is the point to have it there, as long as it will be handled by the last step Return min(len, 2^53-1). anyway.

Most helpful comment

@chozzz sure.

That's my exact point: if it is fine to expect -Infinity less than zero, then it would be equally fine to expect +Infinity greater than 2^53-1.

All 7 comments

I think this is a case where the redundancy does no harm and is actually helpful to readers of the spec.

Readers look at the ToX abstract operations when they need verify, for themselves, how specific cases are handled. In such situations it is easier to see an explicit statement of how +Infinity is handled than to have to remember or lookup that max() is defined to work with +Infinity.

This step was an useful reference when I wrote tests for TypedArrays, I imagined the same applies to runtime implementors. That's a case when clarity wins brevity.

@allenwb @leobalter then for consistency it should be another step that checks for -Infinity.

If len is -Infinity return +0

@zerkms They already did that on step 2.

If len ≤ +0, return +0.

@chozzz sure.

That's my exact point: if it is fine to expect -Infinity less than zero, then it would be equally fine to expect +Infinity greater than 2^53-1.

Editorially I am fine with the current spec text in this regard.

There is now evidence of three people being confused by this. Since the min part is fairly straight forward I guess we'll remove the redundant check and rely on implementers to understand how max/min work with +/-Infinity.

Was this page helpful?
0 / 5 - 0 ratings