extract uint128 package?
josharian opened this issue · comments
I suggest we refactor out our 128 bit support in a go4.org package.
Perhaps it will be of use to the people engaged in golang/go#9455 —and perhaps uses of that package will help make the case for a uint128 in the language. And it’d also provide a nice foil for compiler optimizations I have pondered to provide hardware support for some 128 bit operations using the existing language, like shifts.
I guess "no new dependencies" isn't a great argument when we already depend on intern and its go4.org/unsafe/assume-no-moving-gc, so I guess I have no real objections, other than maintenance overhead.
It is kinda nice having it in the same package so it's easy to quickly add another operation when needed. Maybe it's done-ish, though, and we won't need more stuff for a bit.
The name will be worse in a new package too. uint128.Uint128? int.U128? Or what?
I think it’s done enough to be extracted without much pain. The name is a bummer though. Ideas:
- wide.Uint128 (wide data types)
- c2.Uint128 (twos-complement)
- universe.Uint128 (things that belong in universe scope)
- xtype.Uint128 (extra/extended types)
- uint128.T (T for Type)
- int128.U (U for unsigned, I or S for signed)
I kinda like the "universe" option. If you really wanted to, you could even dot import it (yuck, I know) to remove the package name.
Another reason to do this (eventually) is that they'd be useful in finishing up a SMART implementation.
My personal favorites, some days later, are wide.Uint128, uint128.T, and int128.U.
What about u128.Uint? It has some nice properties: uint is already a Go type of undefined size. The 128 will always accompany it in its types name to disambiguate the length. And the package name of u128 prevents scope creep of adding other helper types.
Unsure how useful this is, but I wrote a uint128 package a while back that has proved somewhat popular. My solution to the naming problem has been...to just copy over the implementation and rename the identifier. Often your program only needs a handful of methods anyway, so you can copy a small amount of code, slap a nice identifier on it, and avoid a dependency to boot.
The copying approach might be less viable if you add serious optimizations, though (particularly asm).