In spec/grains_spec.cr:30:33
30 | Grains.square(64).should eq(9223372036854775808)
^
Warning: 9223372036854775808 doesn't fit in an Int64, try using the suffix u64 or i128
In spec/grains_spec.cr:52:28
52 | Grains.total.should eq(18446744073709551615)
^
Warning: 18446744073709551615 doesn't fit in an Int64, try using the suffix u64 or i128
I believe this “Warrning” was created after the version the test runner runs on.
So yes, when writing integers bigger than int64, you should declare them with <number>_i128.
Crystal as of recently has been a bit weird around integers 128, things are getting improved and is a lot better than the version the test runner is running.
The test hasn’t declared _i128 because the version of crystal the test runner is running on would generate errors if we did that, here is a pr that had to do an “emergency” rollback because it used just the _i128 syntax: [Armstrong numbers]: Emergency rollback by meatball133 · Pull Request #312 · exercism/crystal (github.com).
For now, it is not much to do, the tests will be updated when the test runner gets updated. I am working on improved tooling for testing at the moment, which hopefully will do so the test-runner is more stable and that the testing doesn’t have to take as long.
I am also working on improving crystal lang to make int128 as good as possible before the test runner gets its update, for example char will get an int128 method in 1.8: Added so char can be converted to int128 by meatball133 · Pull Request #12958 · crystal-lang/crystal (github.com)
And I am also looking into how int128 support can come to json.
Thereby I will wait until 1.8.x until the test runner is finished so some int128 improvements can arrive and I have better test tooling.
2 Likes