second draft: add Bitfields to D

[Walter Bright]

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. std.bitmanip.bitfields also implements 
it as a union, 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.)

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., are always crippled and would probably be better off using 
Excel as their programming language :-/


>> 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.


> 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.


> 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.


> 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.