Open jamesderlin opened 3 years ago
@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.
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.
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?
The documentation for
Int32
andInt64
state: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: