third draft: add bitfields to D

[IchorDev]

On Monday, 29 July 2024 at 13:26:29 UTC, Quirin Schroll wrote:
> I don’t; I rather meant specification-level optimization, i.e. 
> D should find its own layout which would be fully specified and 
> need not be compatible with C. In that regard, e.g. if you had 
> `ubyte{7} a, b` (or `ubyte{7}[2]`), the language could require 
> the bits to be laid out as:
> ```
> AAAA AAAB BBBB BB00
> ```
> or
> ```
> AAAA AAA0 BBBB BBB0
> ```
> (`A`: bit part of `a`; `B`: bit part of `b`; `0`: padding)
>
> The specification could say: “A block of bit fields occupies 
> exactly the sum number of bits rounded up to the next multiple 
> of 8. The difference in those numbers is called *padding bits.* 
> If after a bit field a byte boundary is not reached and the 
> next bit field would overstep the next byte boundary and enough 
> padding bits are left to align the next bit field with that 
> byte boundary, exactly that many padding bits are inserted 
> here. Otherwise, bit fields are laid out directly next to each 
> other. Remaining padding bits are inserted at the end of a bit 
> field block.” This is not a suggestion, but a demonstration how 
> a spec can optimize; layout would be predictable.

Ah, thanks for explaining! I always find padding rules to be 
confusing, but as long as there’s a way to disable padding (w/ 
`align(1)`?) I don’t mind.

Also about reserving a new keyword, I was thinking something with 
an underscore like `bits_struct` is unlikely to break any 
existing code, since snake case is not conventionally used for D 
identifiers.