Overflow behavior isn't documented about fixnum HOT 3 OPEN

@jamesderlin thanks for this issue. I feel like the implementation is likely also not correct in that case because (at least from what I understand), the goal of Int64 should be to emulate the behavior of Dart's int in native (just adding web support), but it does not work that way.

Instead, any overflow of Int64 results in -2476544402191318784, unfortunately (so no matter the overflow, you always get that number on web. On native, it works correctly.

from fixnum.

the goal of Int64 should be to emulate the behavior of Dart's int in native (just adding web support), but it does not work that way.

I switched roles at work ~5 years ago and don't work on this package any more, but that wasn't the goal when we wrote this package, mostly because at the time Dart's int behaviour on the VM was effectively the same as Python integers. The Dart int type moved to 64-bit integers long after this package went stable. It probably should be the goal now, but we have backward compatibility to worry about, so we'd want to be very careful with any changes to the semantics other than bugfixes.

Instead, any overflow of Int64 results in -2476544402191318784, unfortunately (so no matter the overflow, you always get that number on web. On native, it works correctly.

Can you file this as a separate bug and link here? The goal of the package is to have the same behaviour on the web and VM; if that's not happening, then it's a bug. We should add additional cases to the overflow tests.

from fixnum.

Instead, any overflow of Int64 results in -2476544402191318784, unfortunately (so no matter the overflow, you always get that number on web. On native, it works correctly.

@creativecreatorormaybenot I don't think that I've observed that. Do you have a specific reproduction case?

from fixnum.