Wouldn't this be better with bitfields?

[Dukc]

Walter Bright kirjoitti 3.7.2024 klo 21.04:
> 
> Then they won't be compatible with C bitfields.
> 

Were in agreement we should have two bit field types (A well-specified 
one that's `std.bitmanip` one, and the C-compatible one) if we count the 
library implementations. I don't think other people have issues with 
that either.

The question is, why does the C-compatible one have to be the 
language-level one? What's the problem in having `std.bitmanip` as the 
language level field while still providing the C-compatible bitfield via 
a DRuntime or Phobos API?

I have readen your take on this from the latest DIP revision:

> Many methods were proposed to deal with this. The only time the layout matters is with Usage No. 3, where the layout is imposed externally. For Usage Nos. 1 and 2, the particular layout does not matter. When it does matter, many alternatives are available:
> 
>     Use https://dlang.org/phobos/std_bitmanip.html#bitfields
>     If one sticks with one field type (such as int), then the layout is predictable in practice, although not in specification
>     Use custom functions to encode/decode fields
>     A bit of testing will show what a particular layout is, after which it will be reliable
> 
> The alternatives are easy enough, and Usage No. 3 is unusual enough, that the extra language complexity to support multiple layouts is not worth it. Note that the author would use a lot more bitfields if they were in the language.

This doesn't really answer the question though, because in my view at 
least we could just as rightfully write:

The objections revolve around discomfort with the layout being 
incompatible with the associated C compiler. Many methods are there to 
deal with this. The only time this is needed is Usage No. 2, where the 
layout is imposed externally. For Usage No. 1, C compatibility does not 
matter and for 3 it would be less practical to use, being implementation 
dependant. When C compatibility is needed, many alternatives are available:

     Use the C-compatible DRuntime bitfield API
     If one sticks with one field type (such as int), then the layout is 
same as with D in practice, although not in the C specification
     Use custom functions to encode/decode fields
     A bit of investigation will show what the C bitfield layout is, 
after which it can be translated to a D bitfield, possibly with 
`version` statements to deal with differences between compilers.

The alternatives are easy enough, and Usage No. 2 is nonstandard enough, 
that the extra language complexity to support multiple bitfield types at 
language level is not worth it. Note that the author does need to use 
mentioned alternatives a lot anyway to integrate with underspecified C 
types, such as `long`.

So, is there something wrong with this take?