it is not hard at all. It is “impossible” because you can’t retrofit the standard library’s String api to use it.
just a meme
1 Like
Yes it is, similar but better than my packed struct version as it asserts the bit offset to be byte aligned.
bitOffset and byteOffset don’t need to be forced to be comptime, the result of built-in functions are almost always comptime known, and if all of the values in an expression are comptime known then the expression will be comptime known, excluding function calls.
Just an FYI in case you didn’t know, it is good to force comptime anyway as it will compile error if you accidentally make something runtime known.
I think the normal struct version earlier is the way to go, as packed types are backed by an integer so often have less desirable code gen, it also has less pointer shenanigans so less opportunity for human error in the implementation.
It can also be extern which I did at first, before realising it no longer depended on field order, which the packed version does. So can be used with C/C++.
I feel like that sounds diminishing of your work? Not intentional at all if it does 
1 Like
Na its fine, I was mostly experimenting with how far I can go since I don’t have much experience with working with types like these.
I mostly put the comptimes even though it works without so it’s easier to read and know that this won’t run at runtime even though they are implied and are not strictly needed.
And I also used the @bitOffsetOf instead of doing a @sizeOf on the type of the length right before doing the pointer math to make it more clear (and less error prone)
I’m still figuring some stuff out (I barely understand align) and there are a few things I am not sure about, like the CedarDB article mentions stealing 2 bits from the pointer to store a tag / what type of string it is. but I am less sure on how stable / reliable this is. if it can be done safely, I am not even sure if to take them from the beginning or the end.
Also I did make some minor changes the version I posted here (and added some comments) and put it on gh gist if anyone wants to copy/use it for anything
1 Like
depends on the platform and how you do it.
I think the safest and most universal way would be to enforce an alignment of 4, that ensures the 2 least significant bits are never used by valid pointers.
You could also exploit unused bits in pointers, but that is highly architecture dependant. It is possible different architectures have the same pointer anatomy, but I simply don’t know what each architecture does.
1 Like