DIP: add Bit Fields

[Walter Bright]

On 3/22/2024 7:32 PM, Steven Schveighoffer wrote:
> 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?

I don't see an actual use case for our own layout. They may indeed be whims on 
the part of the C compiler, but we deliberately pick which C compiler is the 
"associated C compiler", and why pick a nutburger compiler?

> Pick the "right way", define it,

There isn't a right way.

> 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?

One of the uses of bitfields in D is interoperation with C code. It's not 
unreasonable to have a program that is half in D and half in C. Having different 
bitfield layouts would just be an aggravation. It would be surprising.


> 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.

We copy the dumb way C passes arguments to functions, too. Why? Because it's 
convenient, easy to explain, nobody questions it, etc. D in the past had a 
slightly better way of calling C code, and we abandoned that because the 
nuisance of being different simply was not worth it. Changing it to match C made 
the problems and the endless effort explaining the difference just go away.

The value of "it is the same as C" is quite large.


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

ok