second draft: add Bitfields to D

[Timon Gehr]

On 4/23/24 03:01, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/dcb8caabff76312eee25bb9aa057774d981a5bf7/bitfields.md

> In practice, however, if one sticks to int, uint, long and ulong bitfields, they are laid out the same.

Maybe only those cases should be allowed without `extern(C)`. I think 
that might be an ok compromise.

However, I would still much prefer a solution that explicitly introduces 
the underlying `int`, `uint`, `long` and `ulong` fields, which would be 
the ones visible to introspection in a portable way, so that 
introspection code does not really need to concern itself with bitfields 
at all if it is not important and we do not break existing introspection 
libraries, such as all serialization libraries.

> Symbolic Debug Info

This does not seem like a strong argument. I am pretty confident debug 
info can work pretty well regardless of how D lays out the bits.

> ["a", "b", "c"]
> ["a", "_b_c_d_bf", "b", "b_min", "b_max", "c", "c_min", "c_max", "d", "d_min", "d_max"]

I like that the members are not as cluttered. I guess maybe some people 
still would like to access the underlying data (e.g., to implement a 
pointer to bitfield as a struct with a pointer plus bit offset and bit 
length, or something), so perhaps you could add a note that explains how 
to do that.

You forgot to say what `.tupleof` will do for a struct with bitfields in it.

> There isn't a specific trait for "is this a bitfield".

I think it would be better to have such a `__traits` even just for 
discoverability when people look at the `__traits` page to implement 
some introspection code.

> testing to see if the address of a field can be taken, enables discovery of a bitfield.

Not really, a field could be an `enum` field, and you cannot take the 
address of that either. And if we ever add another feature that has 
fields whose address can be taken, existing introspection code may 
break. It is better to be explicit.

> The values of .max or .min enable determining the number of bits in a bitfield.

I do not like this a lot, it does not seem like the canonical way to 
determine it. `.bitlength`?

> 
> The bit offset can be introspected by summing the number of bits in each preceding bitfield that has the same value of .offsetof.

I think it would be much better to just add a `__trait` for this or add 
something like `.bitoffsetof`. This is a) much more user friendly and b) 
is a bit more likely to work reliably in practice. D currently does not 
give any guarantees on the order you will see members when using 
`__traits(allMembers, ...)`.