DIP: add Bit Fields

[Timon Gehr]

On 3/8/24 20:52, Walter Bright wrote:
> 
> There are two dominant schemes today, VC and gcc. I'm not aware of any 
> other scheme for a modern C compiler (Digital Mars C emulates the VC 
> layout). Even so, VC and gcc lay things out the same way for `int` bit 
> fields. This is never going to change.

Well, if you believe this, why not specify the behavior?

Similarly, if you believe a specced-out `extern(D)` vs a "companion 
compiler" `extern(C)` would not make a difference anyway, why is it a 
concern to you that they could be accidentally confused?

And finally, why not just require an _explicit_ specification of the 
layout on the D side?

E.g., something like:

```d
int x {
     int a : 2;
     int b : 18;
     int c : 11;
     int : 1; // sign bit reserved
}
```

(x.a, x.b, etc.)


or perhaps even:

```d
int {
     int a : 2;
     int b : 18;
     int c : 11;
     int : 1; // sign bit reserved
}
```

Then make the compiler enforce that the fields add up to the size of the 
type. By default this is compatible with what VC and GCC do, and ImportC 
can just uniformly translate the imported C code to such an explicit 
layout spec. It will even be intuitive.

Just make it portable across machines with the same endianness, like the 
built-in integer types already are. This optimizes the user experience 
at the same time: It will usually be obvious how big a struct is, there 
will not be a need to add together the sizes of bit fields in order to 
figure out how things are laid out in memory.

In any case, the introspection story needs to be fixed. (Even just for 
the sake of introspecting structs originating in ImportC code.)

This would be so much better and improve ImportC at the same time.