Redundant step in Array.prototype.splice

[acutmore]

Description: Array.prototype.splice could be editorially simplified

When reviewing tc39/proposal-change-array-by-copy#74 (comment), @syg pointed out that Array.prototype.toSpliced has a redundant step specifically handling -∞. Which could be reduced as so:

- 4. If relativeStart is -∞, let actualStart be 0.
- 5. Else if relativeStart < 0, let actualStart be max(len + relativeStart, 0).
+ 4. If relativeStart < 0, let actualStart be max(len + relativeStart, 0).

This part of the proposal was a direct copy of the current Array.prototype.slice spec, so the same simplification can be applied there; pressuming we'd want to keep splice and toSplice matching steps where possible.

Looking back this line was introduced as part of #2007

ES2020: https://262.ecma-international.org/11.0/#sec-array.prototype.splice

3. Let relativeStart be ? ToInteger(start).
4. If relativeStart < 0, let actualStart be max((len + relativeStart), 0); else let actualStart be min(relativeStart, len).

ES2021: https://262.ecma-international.org/12.0/#sec-array.prototype.splice

3. Let relativeStart be ? ToIntegerOrInfinity(start).
4. If relativeStart is -∞, let actualStart be 0.
5. Else if relativeStart < 0, let actualStart be max(len + relativeStart, 0).

[syg]

We discussed this on the editor call, and I retract my original suggestion @acutmore. Even though arithmetic on the extended reals is defined, I'm convinced that we should still err on the side of being extra explicit and keep the current language. Same applies for your proposal, please revert the change you made on my suggestion. Apologies for the churn.

For completeness, the reasoning is that when an arithmetic is on aliases like it is in this case, len + relativeStart, allowing extended reals makes it harder to reason about if it is in fact an indeterminate form, having to trace if both aliases can be an infinity.

[acutmore]

Thanks for discussing, great to have a quick resolution 🙂