Overflow behavior isn't documented

[jamesderlin]

The documentation for Int32 and Int64 state:

Arithmetic operations may overflow in order to maintain this range.

but doesn't explain what the overflow behavior is. Does it wrap around? Is it clamped? Is it like signed integer "overflow" in C where it's undefined behavior?

In contrast, the documentation for int states:

The default implementation of int is 64-bit two's complement integers with operations that wrap to that range on overflow.

[creativecreatorormaybenot]

@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.

[cbracken]

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.

[jamesderlin]

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?