Is -0 < 0, regarding [EnforceRange]?

[domenic]

[EnforceRange] will throw a TypeError

If x < lowerBound or x > upperBound, then throw a TypeError.

If lowerBound is 0 and x is -0, will this throw? Note that -0 < 0 is false in JavaScript.

The answer might be well-defined by ECMAScript conventions, but we should check that it is, and in any case we should add a note about this explicit case.

Note that the [Clamp] and no-extended-attribute cases don't have this problem as they explicitly censor -0 to 0. Although I guess clamp is a bit ambiguous, if "round -0 to the nearest integer choosing 0 instead of -0" will in fact change -0 to 0.

[domenic]

One of the simplest ways to clear this up might be for the top of the algorithm to just immediately set x to +0 if x is -0.

[bzbarsky]

If lowerBound is 0 and x is -0, will this throw?

I would hope not!

Note that -0 < 0 is false in JavaScript.

Sure. It's false in IEEE-754 in general, I believe. That is, -0 < 0 is false in C/C++/Rust/etc as well, as far as I know.

But we could be pretty explicit about this, sure.

[annevk]

I guess we should say we use IEEE-754. Might become more important with wasm bindings, though just spitballing here.

[bzbarsky]

Well. The return value of ToNumber is an ES Number, and those are defined https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type as:

The Number type has exactly 18437736874454810627 (that is, 2^64-2^53+3) values, representing the double-precision 64-bit format IEEE 754-2008 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 2^53-2) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value.

We could try to be more explicit here, I guess, but we're working with a Number value here....

[domenic]

It's just unclear to me (both here and in the ES spec) whether when you do thinks like <, max(), 2^bitLength, etc. you are dealing with mathematical numbers or IEEE-754 numbers. In particular 2⁶⁴ is not accurately representable with IEEE-754 so given "x < 2⁶⁴" it seems like the left-hand side is IEEE-754 and the right-hand side is mathematical, so I'm not clear in general whether < is mathematical or IEEE-754.

[bzbarsky]

Ah, that's a good point. This part is definitely sucky. :(

[tobie]

In particular 264 is not accurately representable with IEEE-754 so given "x < 2⁶⁴" it seems like the left-hand side is IEEE-754 and the right-hand side is mathematical, so I'm not clear in general whether < is mathematical or IEEE-754.

We never have that case, though. First step of the algorithm says:

1. If bitLength is 64, then:
   1. Let upperBound be 2⁵³ − 1.

[tobie]

Oh. Nevermind. We have similar issues in step 9 and 10:

9. Set x to x modulo 2^bitLength.
10. If signedness is "signed" and x ≥ 2^{bitLength − 1}, then return x − 2^bitLength.

:-/

[tobie]

Digging into this a bit further, from § 5.2 Algorithm Conventions in the ES spec says:

Mathematical operations such as addition, subtraction, negation, multiplication, division, and the mathematical functions defined later in this clause should always be understood as computing exact mathematical results on mathematical real numbers, which unless otherwise noted do not include infinities and do not include a negative zero that is distinguished from positive zero.

So I assume:

1. If x < 2⁶⁴, then …

really means:

1. Let x' be the mathematical real number that has the same numeric value as x.
2. If x' < 2⁶⁴, then …

If this assumption holds, I could add a little bit of text at the beginning of § 3.2.4. Integer types that paraphrases the above quote and links to its source.

[domenic]

But how would you interpret "return x" then? Does it allow returning -0? Again that seems unlikely since a Web IDL byte type (say) doesn't have a -0.