How about just allowing bitwise operations on byte arrays (of the same
length)?
On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
> I'm not 100% sure if this is a good idea but it's been knocking around
> in my head all week so I thought I'd share in case it has any merit:
>
> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
>
> These are similar to uintN but they are unordered and have no
> arithmetic operations defined.
>
> They only have literals, comparison, and bitwise operations.
> (fmt.Print and friends should render them in hex by default.)
>
> Conversions between the numeric types and the bitN are allowed, which,
> for example, let's us rewrite math.Float64bits as simply
>
> func Float64bits(f float64) uint64 {
> return uint64(bits64(f))
> }
>
> Since there are no arithmetic operations, the 128+ sizes should be
> fairly efficient to fake on architectures without special
> instructions/registers.
>
> Potential uses:
>
> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
>
> SIMD vectors could be created and stored easily, even if they need
> assembly to operate on them efficiently.
>
> Same for int128/uint128 values or even for more exotic numeric types
> like the various float16 definitions or "floating slash" rationals.
>
> It would also be handy to have larger bitsets that are easy to work with.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d0507019-b796-47b6-a4e9-3e407879866cn%40googlegroups.com.
