second draft: add Bitfields to D

[Timon Gehr]

On 4/30/24 05:30, Walter Bright wrote:
> On 4/29/2024 5:04 AM, Timon Gehr wrote:
>>> If they are not checking for bitfields, but are just looking at 
>>> .offsetof and the type, they'll interpret the bitfields as a union 
>>> (which, in a way, is accurate).
>>> ...
>>
>> No, it is not accurate.
> 
> Getting and setting bit fields reads/writes all the bits in the 
> underlying field, so it definitely is like a union.

No, more than one bitfield is valid at a time even if they have the same 
offsetof. This is definitely breaking expectations that used to be true.

> std.bitmanip.bitfields also implements it as a union,

No, this is not correct. It implements it as a field with accessors for 
different groups of bits. The only reason why `union` appears in that 
file is to support bitfields inside a union. This again highlights that 
those are not the same thing.

> because there is 
> no other way. The CPU does not provide any instructions to access bit 
> fields. (This is why atomics won't work on bitfields.)
> ...

Sure! I guess this opens the question what happens with bitfields and 
type qualifiers. The DIP currently says you can have `int`, `uint`, 
`long` and `ulong` bitfields.

Are e.g. `immutable(int)` bitfields allowed?
I'd expect `shared(int)` bitfields are not allowed?


> If the user of bitfields does not understand the underlying physical 
> reality of bitfields, they will forever have problems with them. Just 
> like programmers who do not understand the physical reality of pointers, 
> floating point, 2s complement, etc.,

I understand the underlying reality of all of those concepts and I still 
disagree that interpreting bitfields as a union is correct. There are 
bitfields and there are unions.

> are always crippled and would 
> probably be better off using Excel as their programming language :-/
> ...

However, this seems like an exaggeration. I think there are programmers 
who are gainfully employed and fall into neither of those categories.

> 
>>> Pointer to bitfields will work just the same as they do in C. I don't 
>>> understand what you're asking for.
>> Well, you can't take a pointer to a bitfield.
> 
> Exactly what I meant!
> 
> 
>> Well, so far everything in `.tupleof` had an address.
> 
> When you mentioned enums not having an address, I had assumed you were 
> talking about __traits(allMembers). .tupleof skips over enums.
> ...

But it will include bitfields, and not the underlying "physical" variables.

> 
>> It should at least be mentioned in the DIP, if nowhere else you should 
>> put it in the breaking language changes section.
> 
> I can mention it, sure.
> ...

Thanks!

> 
>> Well, if you are trying to deliberately make introspection 
>> unnecessarily complicated, I guess that's your prerogative.
> 
> __traits has an ugly syntax. The idea was to provide the ability, and 
> the user (or Phobos) would put a pretty face on it.
> ...

In practice people often do use `__traits`, either because it is more 
efficient or wrapping is impossible. In any case, providing exactly what 
is needed is much simpler.

> 
>> All of those things are ugly hacks. This kind of brain teaser is how 
>> metaprogramming works (or increasingly: used to work) in C++, but I 
>> think it is not very wise to continue this tradition in D.
> 
> std.traits definitely continues the tradition. While I'm fine with ugly 
> implementations in it, std.traits fails to document the behavior of the 
> functions that supposedly put a pretty face on it. I've asked Adam 
> Wilson to consider completely re-engineering std.traits.
> 
> As long as it is possible to put a pretty face on it, I'm ok with an 
> underlying ugliness in the service of not having N>1 diverse ways to do X.
> 

I think the main thing is it should be immediately obvious to readers, 
as it is actually not hard.