second draft: add Bitfields to D

[Walter Bright]

On 4/26/2024 8:26 AM, Steven Schveighoffer wrote:
> Suffers from the same major problem as last time - nobody is going to be using C 
> bitfield structs from D,

I am, as soon as they become available in the D bootstrap compiler. I don't much 
care for the ugly workarounds used currently.

> yet we are inheriting all the problems.

There aren't any problems if one is using bitfields for reducing memory 
consumption or for C compatibility.

> Keeping C compatibility is meaningless.

In the D compiler source code, it means gcd and ldc with their C++ backends 
won't have any issues with it.

> Have you considered that people might build some libraries with ldc, but build 
> applications with dmd? If LDC picks one mechanism for laying out bitfields, but 
> DMD picks a different one, then what happens when you try to use the two 
> together? Do we really want to make D incompatible with itself?

I have considered that. dmd will pick the same layout as the associated C 
compiler, which is gcc (used by gdc), and clang (used by ldc).

> This already happens with C. See for instance 
> https://stackoverflow.com/questions/43504113/bitfield-struct-size-different-between-gcc-and-msft-cl

Can you even mix/match object files between vc and gdc, or vc and ldc, anyway?

dmd on Windows generates DMC layout for -m32, and VC layout for -m64 and -m32mscoff


> Adding more `__traits` is trivial, don't skimp here.

Can be added later. The point is, the information is available.


> Still does not address `sizeof`.

Oops forgot that. It would return the size of the bitfield's type.

> The mechanism described to get the bit offset is... horrific. Please just add 
> some `__traits`.

It can be added later. But in general it is not a good idea to add things that 
are deducible from existing things. In this case, it's a loop. A function could 
be written to do it.