Sdk: int.parse has limited precision, contradicting docs

[trinarytree]

For dart 2,

> dart --version
Dart VM version: 2.0.0-dev.52.0+google3-v2.0.0.dev.52.0 (google3) on "linux_x64"

the following

int.parse('230423094239402322234');

yields

FormatException: Invalid radix-10 number

because apparently int has bounded precision in dart 2. More evidence of its bounded precision:

var n = 2304230942394023222;
for (var i = 0; i < 4; i++) {
  n *= 2;
  print(n);
}

yields

9216923769576092888
-12896534557365840
-25793069114731680

Notice how it overflowed and became negative. In fact, it seems like the largest integer dart 2 can parse is 2^63-1 = 9223372036854775807.

The dart 2 docs for int here say

int class
An arbitrarily large integer.

So the docs are wrong.

For dart 1,

> dart --version
Dart VM version: 1.24.3 (Wed Dec 13 23:26:59 2017) on "macos_x64"

the following

int.parse('2304230942394023222349034583405983450384509');

yields

which makes me believe that for dart 1, int is an arbitrarily large integer, but for dart 2, it's basically Int64.

In the "differences" section of the dart 2 welcome page, you'd think that this might be mentioned... changing the fundamental semantics of one of the most important types in the language.

Assuming this change was intentional, can it be added to the differences section, with an explanation, and worked into the API docs? So far, the only hint I found about this change is a vague comment by rnystrom here in 2015 saying that he doesn't think arbitrary precision ints are worth it.

[zoechi]

Seems some docs need to be updated. The CHANGELOG.md mentions it though

(last link in )

[natebosch]

@alexmarkov - it looks like we need to track down stale documentation after the 64 bit int changes.

[alexmarkov]

/cc @kwalrath

[trinarytree]

I'm seeing some more subtle, undocumented behavior from int.parse. Apparently, it treats base 16 differently from every other base (in more ways than the obvious one):

print(int.parse('7fffffffffffffff', radix: 16)); // 9223372036854775807
print(int.parse('8000000000000000', radix: 16)); // -9223372036854775808, not overflow???
print(int.parse('9223372036854775807')); // 9223372036854775807
print(int.parse('9223372036854775808')); // throws, apparently considered overflow

This is inconsistent. Something (in integers_patch.dart, _parseRadix) detects that when the radix is 16 - not 2, 4, 8, nor 32 - that the input should be parsed as an _unsigned_ int, but for every other base, it should be parsed as a _signed_ int, resulting in different overflow boundaries.
None of this is documented. Assuming this inconsistent behavior is desired, please at least document it.

Taking a step back, why would we want int, which is signed, to be sometimes parsed as though it's unsigned? If one wanted an unsigned int, wouldn't it make more sense to have a more explicit signal than the radix, e.g. parse(source, signed: false)? I mean, look at this wackiness:

print(int.parse('-8000000000000000', radix: 16).toRadixString(16)); // -8000000000000000
print(int.parse('8000000000000000', radix: 16).toRadixString(16)); // -8000000000000000

In the 1st case, I'm parsing an unsigned int... except that I put a negative sign in front of it... and that's not an error.

[kwalrath]

@lrhn Who'd be a good person to fix the doc comments?

[lrhn]

This guy: https://dart-review.googlesource.com/c/sdk/+/58204 :)

There is a separate handling of overflowing hex numbers in int.parse with "0x" prefix and no radix. See also #32858.
Maybe that's a bad idea. It seems hard to explain :)

[natebosch]

https://dart-review.googlesource.com/c/sdk/+/58204 is in and reflected in the docs for the current SDK. Looks like the parse stuff was handled in a separate issue.