DIP: add Bit Fields

[Dennis]

On Thursday, 7 March 2024 at 19:42:36 UTC, Walter Bright wrote:
> If you like a nice syntax, bit fields cannot be beat.

There's no need to argue that native bit fields look nicer than 
manual bit shifts. Of course they do.

> And yes, you can't do volatile, shared, atomic, or pointers to 
> bit fields.

Of course you can't. No need to defend this.

The main question is: Why inherit C's controversial inconsistent 
layout scheme? The DIP keeps going on about C interoperability, 
but only cites abstract "experience" as an argument.

My last use of bit fields was from optimizing `std.uni` tables: 
https://github.com/dlang/phobos/pull/8880
Wouldn't it be nice if I could use the shiny new bit fields 
feature for that? Well I can't: the table needs to know the bit 
offsets, which would be target dependent. I'd have to use the 
inferior `std.bitmanip`. If I didn't know about the platform 
dependence, I'd use bit fields incorrectly. It would all work 
until compiling to a different target results in a corrupted 
table, without warning. After debugging and finding the cause I'd 
write a blog post "D bit fields considered harmful" like C users 
have done before.

Why bow down to C and treat D as a second class citizen? The DIP 
should really substantiate this alleged importance of 
C-compatibility of non-ImportC D bitfields: Can you name at least 
one dub package that would benefit from bit fields with 
C-compatible layout?