You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been discussed before but there is some awkwardness. Currently, all integer types are aligned to their size. Should UInt128 be aligned? Well, practically speaking, it would be pretty hard to achieve that since Cap'n Proto objects in general are only aligned to 64 bits, and the underlying memory allocator probably is too. But, some people who have requested a UInt128 type actually do want it to be 128-bit aligned, for use in vector instructions that require this.
If UInt128 is only 64-bit aligned, it may be easier to implement, but it's still awkward in a different set of ways. It would have to work differently from all the other integer types.
Another solution that has been floated is the idea of "inline structs". Then you cloud declare a UUID struct with two UInt64 members, and inline it into other structs for efficiency. A much more general solution. But also a lot more work to implement, obviously.
In any case, no one is jumping to work on any of these, so we're probably stuck with using a pair of UInt64s, which, while ugly, has worked out fine in my experience.
Today, a UUID can be represented in capnproto using the following ways:
:Text
, requiring 8-byte pointer + 36 bytes (40 bytes total):Data
, requiring 8-byte pointer + 16 bytes (24 bytes total):UInt64
representing the lower 64 bits and upper 64 bits. (16 bytes total), but requires consumers to convert it properly.It would be great if capnproto supported
:UInt128
or a native:Uuid
type to represent this data using only 128 bits (16 bytes).The text was updated successfully, but these errors were encountered: