Casting `infinity` to integer makes value `0`

[cometkim]

let t1 = infinity->Belt.Float.toInt
let t2 = infinity->Float.toInt

generates

import * as PervasivesU from "./stdlib/pervasivesU.js";

var t1 = PervasivesU.infinity | 0;

var t2 = PervasivesU.infinity | 0;

both are 0. so we don't actually have a way to compare int value with the infinity without %raw. because infinity in pervasive is float

Infinity is often used in arithmetic operations as well as a value indicating "no limit" (e.g. pagination)

#6038 also mentioned

[cometkim]

Maybe we could guide the user by adding infinity_int etc, but it doesn't seem intuitive. Honestly I just made a bug by this, and didn't suspect it for several minutes of debugging.

[mununki]

I guess the compiler uses the bitwise operation to convert float to int e.g. 1.1 | 0 I think we should handle differently with Infinity. What do you think?

[cometkim]

Yes for sure. It would be nice to have poly infinity, since not, at least there should be something to avoid pitfalls

[mununki]

Indeed, since we don't have a polymorphic number type, we have to handle it to avoid pitfalls.

[cometkim]

since we don't have a polymorphic number type

or can we make it a keyword? then it can act like a polymorphic

[mununki]

Another pitfalls:

let t4 = (22130921800000. -. 0.)->Belt.Float.toInt
let t5 = (22130921800000.)->Belt.Float.toInt

generates

var t4 = 22130921800000 - 0 | 0; // -1044676288
var t5 = 2147483647; // max value of Int32

[mununki]

since we don't have a polymorphic number type

or can we make it a keyword? then it can act like a polymorphic

This issue doesn't seem to be one that can be solved with types. I think we need to rethink the rules for converting Float to Int.

[cometkim]

Another pitfalls:

let t4 = (22130921800000. -. 0.)->Belt.Float.toInt
let t5 = (22130921800000.)->Belt.Float.toInt

generates

var t4 = 22130921800000 - 0 | 0; // -1044676288
var t5 = 2147483647; // max value of Int32

Honestly, this example doesn't feel like a trap to me. That's a natural property of the int(32) type in arithmetic.

It looks like another kind of problem 😅

22130921800000 - 0 | 0; // -1044676288 seems to happen because the implementation of Belt.Float.toInt is specially stripped by the compiler instead of an actual runtime cast, as expected.

The reason infinity is confusing is that, as mentioned above, it can be used as a kind of flag.

[mununki]

let t5 = (22130921800000.)->Belt.Float.toInt

Shouldn't this also be generated like this, at least in terms of consistency?

var t5 = 22130921800000 | 0;

[mununki]

Side note: Why did the compiler try to optimize numeric operations with Int32 for the int type? Because OCaml's Int64 can handle JS's safe integer (2^53).

[cometkim]

Yes, I expect both examples to be equally 2147483647. but anyway it's a different kind of issue we have

[mununki]

Yes, I expect both examples to be equally 2147483647. but anyway it's a different kind of issue we have

Or, Another option is to not optimize and not change the value in generated js.

[cometkim]

Why did the compiler try to optimize numeric operations with Int32 for the int type? Because OCaml's Int64 can handle JS's safe integer (2^53).

No, it because JavaScript JIT engines are actually perform better with int32. Inside the JS optimizer, there is a clear distinction between numbers that exceed 32 bits and those that don't, and being able to guarantee 32-bit integers in a specific path has huge optimization benefits.

A bit off-topic, JavaScript's subtle number handling causes problems when interoperating with other systems. This often causes interoperability problems with most systems that make a stricter distinction between int32/int64/float32/float64/etc.

For example, GraphQL Int specifies 32-bit precision in the spec, but often larger values are passed by JS clients.

[cometkim]

It might be "correct" for infinity to be of type float if we treat it as a part of the IEEE 754 specification. In that case, it also makes sense to explicitly restrict casting to prevent Infinity from being abused.

However, it still poses problems for interoperability with other JS libraries that use Infinity as a flag.

[mununki]

Okay, I'm still not sure about the rules for converting float values beyond int32 to int actually, but I think the inconsistency between t4 and t5 is another issue. I'll open another issue for it.

Another pitfalls:

let t4 = (22130921800000. -. 0.)->Belt.Float.toInt
let t5 = (22130921800000.)->Belt.Float.toInt

generates

var t4 = 22130921800000 - 0 | 0; // -1044676288
var t5 = 2147483647; // max value of Int32

I agree that int32 coercion process should not happen for infinity.