second draft: add Bitfields to D

[Richard (Rikki) Andrew Cattermole]

On 23/04/2024 1:01 PM, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/dcb8caabff76312eee25bb9aa057774d981a5bf7/bitfields.md

"The specific layout of bitfields in C is implementation-defined, and 
varies between the Digital Mars, Microsoft, and gdc/ldc compilers. 
gdc/lcd are lumped together because they produce identical results on 
the same platform."

s/lcd/ldc/



Worth mentioning here is that as long as you don't use string mixins 
attempting semantic is actually pretty cheap to determine compilability. 
Now that I'm thinking about the fact that its the same entry point 
internally.

Not ideal, will need an example in the specification on how to do this, 
if there is no trait. But in saying that, you'll need to use a trait 
anyway, so...

```d
T t;
enum isNotBitField = !__traits(compiles, &__traits(getMember, t, member));
```

Not ideal.

```d
void main() {
     Foo t;
	enum isBitField = !__traits(compiles, &__traits(getMember, t, "member"));
     pragma(msg, isBitField);
}

struct Foo {
     enum member;
}
```

Okay yes, not having the trait is a bad idea.
It makes introspection capabilities of D have less capability to 
determine what a symbol is.



I also mentioned this previously, but I want to see std.bitmap.bitfields 
gone for PhobosV3.

Anything that uses string mixins that the user interacts with makes 
tooling fail with it.

This is not an acceptable solution to be recommending to people, we can 
do significantly better than that.

It also means that people have to remember and understand the two 
separate solutions that we are recommending that in no way are 
comparable in how they are implemented.