.NET 8: (U)Int128 handling about messagepack-csharp

[pCYSl5EDgo]

Surely, as you say, we can leave it alone until someone is in trouble.
I will wait a few more days and then close this issue. In the meantime, if anyone needs Int128 support, they will comment. I'm sure they will, maybe.
By the way, I myself use UInt128 as a column in my database via EF Core.

endianness

As a messagepack integer, Big-Endian seems appropriate. Vector<128>.Shuffle seems performant.

[pCYSl5EDgo]

I like Option 1.

[AArnott]

There is precedent in this library for inventing our own encoding for a particular type and then conforming to a later msgpack spec while maintaining backward compatibility. Unfortunately, the public bool OldSpec property doesn't scale well to that happening again, but I'm sure we could come up with something.

But I wouldn't rush into it unless there was actually something that needed it.

The concern I have with option 1 is that it doesn't appear to account for endianness. MsgPack already has a 128-bit encoding for Guids. In fact IIRC it has two: a binary copy and one that is 'safe' for cross-endian interop. If we were to do something for 128 bit integers within the library, I think we should start with an cross-endian safe encoding, and couple that with a 'native' binary copy formatter that can be opted into by interested parties.