`type TimeUnit = distinct int128`

[timotheecour]

(placeholder, will add more details)

notes

• bigint doesn't replace int128, and will likely be much slower
• we may need other number types in the future besides int128, eg float80, float16 (half float)

links

• https://github.com/nim-lang/RFCs/issues/383#issuecomment-864460282
• https://news.ycombinator.com/item?id=10909909

  Optimization story: Switching from GMP to gcc's __int128 reduced run time by 95%

• https://stackoverflow.com/questions/16088282/is-there-a-128-bit-integer-in-gcc#comment116127623_16088370

  having an arbitrary-precision library just for a 128-bit type is just too wasteful, and the overhead is just too big. A fixed-width library like Boost.Multiprecision or calccrypto/uint128_t will be much smaller and faster – phuclv Jan 12 at 9:24

libs

https://github.com/status-im/nim-stint/blob/master/stint.nim has multiprecision library, including a Int128, so this is a candidate thing to compare against

func i128*(n: SomeInteger): Int128 {.inline.} = n.stint(128)
func i128*(s: string): Int128 {.inline.} = s.parse(Int128)

[juancarlospaco]

Some day the int128 should be moved into public API, with its features and limitations documented, I do not see a reason to not do it, theres already more "unsafe" stuff in public APIs anyway...

[timotheecour]

it's not about "unsafe", it's about the added complexity, here are the challenges i see:

• compiler code has ~ 85 instances of tyInt64, 41 instances of tyInt32, etc
• the question is whether to add a tyInt128 or a generic tyInteger which can be used to encode new number types (int128, uint128 etc, and possibly later refactor to remove tyInt32 etc to all be represented by tyInteger)
• should we also introduce uint128
• what do we do with bounds checking and overflow detection, both in RT and VM; we added compiler/int128 to avoid overflow issues with uint64+friends, but if we add int128, that obviously won't work anymore (lest we add compiler/int256, which sounds like it'd be inefficient)
• we need to provide both emulation and platform native int128 depending on whether platform has it natively; detection seems easy, via #ifdef __SIZEOF_INT128__, refs https://stackoverflow.com/a/54815033/1426932
• cgen needs to handle converting 128 literals to C code, which is slightly complicated by fact 128 literals don't exist, but it's feasible via things like https://stackoverflow.com/a/51539449/1426932
• should BiggestInt be int128 or stay int64?

I'm still very much in favor of adding int128, but it will require some work

[juancarlospaco]

• https://crystal-lang.org/api/1.0.0/Int128.html
• https://ziglang.org/documentation/master/#Primitive-Types
• https://github.com/golang/go/issues/9455

[timotheecour]

=> filed https://github.com/nim-lang/RFCs/issues/399