DIP: add Bit Fields

[Steven Schveighoffer]

On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/master/bitfields.md

Most of the complaints by the seasoned pros here are of the form: 
C bitfields are an implementation-defined mess, and we shouldn't 
copy them. I don't think this means we can't copy the *good 
parts*.

If I understand correctly, it's because C can do odd things with 
corner cases, not because it's doing insane things like storing 
bitfields in every other bit, etc.

So if "almost all C compilers" do the same thing, why not just 
define that thing, and say D does it this way? Why say we depend 
100% on C compiler implementation whims? If the corner cases are 
problematic, ban the corner cases?

Pick the "right way", define it, and say "This works for most 
cases in all the C compilers we use, and if it doesn't, you have 
to figure it out yourself". I don't understand the problem with 
that. ImportC bitfields *don't have to be the same*. As you once 
told me, bitfields are not generally used for public API, because 
of the complications. So why do we need C compatibility in the 
first place?

C does some really dumb things (hindsight, etc.), and D didn't 
copy all those dumb things. We should continue to not do dumb 
things.

Bitfields should have `__traits` to go with them (e.g. 
`__traits(bitSize, x)` should return `4` for a 4-bit value). 
There is zero reason to hide what the compiler knows. I don't 
know if there are any more things needed, as you can use `typeof` 
to get the underlying type, and getting an address to the full 
bitfield can be done with a union.

There are other things that aren't specified in the proposal, 
such as the properties that work on other basic types: `sizeof`, 
`offsetof`, `alignof`.

-Steve