`array.indexOf(x, -0)` unnecessarily coerces its start offset to `+0`

[isiahmeadows]

In step 7.a of Array.prototype.indexOf's algorithm, it says "If n is -0, let k be +0; else let k be n.". This could be simplified to "Let k be n." just like in Array.prototype.indexOf without observable effect, since ToString(-0) yields "0", not "-0".

Also, as an aside, it might be a good idea to fuse steps 6-8 of Array.prototype.indexOf and steps 6-7 of Array.prototype.includes into a shared abstract operation that does basically this and let the case of n = len initially fall out naturally, simplifying the spec text for both operations (and the corresponding typed array operations):

CoerceOffsetWithLength(n, len):

1. Assert: ToInteger(n) is n.
2. Assert: ToInteger(len) is len.
3. If n ≥ len, return len.
4. If n is -0, return +0.
5. If n ≥ 0, return n.
6. If -n ≤ len, return n + len.
7. Return 0.
8. Assert: ToString(r) is an integer index, where r is the return value.

[zenparsing]

Wouldn't that allow the algorithm to return -0 in 9.c?

[zenparsing]

Wouldn't that allow the algorithm to return -0 in 9.c?

[isiahmeadows]

Good point. You'd have to coerce it in that case, although you could wait until the end to do so. I updated the aside to take that into consideration.

[isiahmeadows]

Good point. You'd have to coerce it in that case, although you could wait until the end to do so. I updated the aside to take that into consideration.