First Draft: Bit Fields

[Nick Treleaven]

On Thursday, 7 March 2024 at 05:00:36 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> "gdc/lcd are lumped together because they produce identical 
> results on the same platform."
>
> s/lcd/ldc/
>
> No mention of alignment, total size or the offset.

Agree, the DIP should mention those. The implementation seems to 
give each bitfield of a set the same value:

```d
struct S
{
     uint a:1,
          b:1,
          c:1;
}
static assert(S.b.alignof == 4);
static assert(S.b.offsetof == 0);
static assert(S.b.sizeof == 4);
```

> Needs to mention atomics as not being supported.

Yes. Bitfield impl doesn't allow shared, static (or even const) 
storage classes.

> No trait to detect a bit field (if its an alias, or by name), 
> nor get its size. Kinda required, enough other things in the 
> language can appear via an alias sequence or by allMembers that 
> are not able to be taken as a pointer of.

Possibly this might be enough (using S above):
```d
enum E
{
     a, b, c
}
struct U
{
     int i;
     alias i this;
     enum max = 2;
}
enum isBitfield(alias a) = __traits(isIntegral, typeof(a)) &&
     !is(typeof(a) == enum) && a.max <= uint.sizeof * 8;

static assert(isBitfield!(S.b));
static assert(!isBitfield!(E.b));
static assert(!isBitfield!(U()));
```

> The ability to take an alias via getMember needs to be 
> considered if its valid to do so.
>
> No mention of tupleof either, what happens there?

Impl:
```d
void main()
{
     S s;
     s.tupleof[1]++;
     __traits(getMember, s, "c")++;
     writeln(s.tupleof); // 011
}
```

> No motivation for not including a D layout for it, instead of 
> forcing everyone into an unpredictable layout that the system C 
> compiler might be using. Moving us off the library type and 
> into a language defined one that is predictable is quite 
> attractive so there needs to be an argument against this.

Just to mention, the argument in the DIP was portability with C 
bitfields.