Int operator inconsistency: some return 32bit truncated ints, some don't.

[drathier]

Rounding: truncate truncates to 32bit, but floor, ceil and round don't.
Operators: // truncates to 32bit, but +, -, *, ^, modBy, remainderBy don't.
Bitwise operators truncate to 32bit.
Json.Decode.int handles -2147483647 < value < 2147483647 plus all finite whole numbers (core, kernel).

I suggest casting all Int return values and limiting literals to 32bit using | 0, even for functions that return numbers, or implementing unbounded integers for everything except bitwise operators.

The non-truncated ints behave funny anyway, since they have float rounding errors:

> 100^10
100000000000000000000 : number
> 100^10+1234
100000000000000000000 : number
> 100^10+12345
100000000000000020000 : number

and they expose float constants:

> round (100^100^100)
Infinity : Int
> round (100^100^100/100^100^100)
NaN : Int

[Erudition]

Just ran into this also. The Unix time right now is 1565370879.000, which corresponds to Elm time 1565370879000, an Int. Yet when I try to work with that Int myself:

truncate 1565370879000
2002783256 : Int

That's the REPL telling me that I can't even use all Int operations on Ints provided by Elm!

This is a big deal. 32-bit Integers only go up to two billion: that's simply not enough. I guess I'll have to use a String-based truncate for now. Yuck.

or implementing unbounded integers for everything

This is the solution. But in the mean time, can we switch to Math.trunc() under the hood? I know the | 0 trick was used because it has better browser compatibility, but since the docs say big Int support is platform-specific anyway, we can just use that as a fallback.

[Janiczek]

This happened to me when handling millisecond UNIX timestamps as well.