third draft: add bitfields to D

[IchorDev]

On Friday, 26 July 2024 at 00:08:12 UTC, Quirin Schroll wrote:
> I like it. The only thing that’s odd to me is `int: 21 foo, 
> bar`. It looks much more like `21` is in line with `foo` and 
> `bar`, but it’s to be read as `int: 21` `foo` `bar`. We could 
> agree to use no space, i.e. `int:21`, or use something other 
> than `:`, e.g. `int{21}`. That looks much more like a type and 
> `int{21} foo, bar` looks much more like a list of variables 
> declared to be of some type. Essentially, `int[n]` is a static  
> array of `n` values of type `int`, whereas `int{n}` is a single 
> `n`-bit signed value. As per `int`, `n` is 32 or lower. For 
> `bool` only `bool{1}` would be possible

Good idea about `int{21}`! The `int: 21` syntax was a bit of a 
cop-out because I couldn’t think of anything better.

> (maybe also `bool{0}`, if we allow 0-length bitfields.

No harm in doing so I suppose. Even better if they’re actually 0 
bytes, heh.

> In general, `extern(D)` bitfields should be allowed to be 
> optimized.

If you mean field reordering, then that did *not* work with 
structs, so I’m inclined to view this idea with some healthy 
skepticism.
First off, we don’t want libraries where every change to a 
bitwise/bitfield is a breaking change. You might say that the 
obvious answer to this is to use the ‘don’t ruin my binary 
compatibility’ `@packed` attribute, but this is not how the other 
PoD aggregates work in D, so it might get largely overlooked.
Second, I think we should trust that devs are smart enough to lay 
their data out themselves.
Field reordering should *at least* be opt-in, but I’d argue that 
it’s not even a necessary feature in the first place. It’s 
something I can’t see myself ever wanting.