second draft: add Bitfields to D

[Timon Gehr]

On 4/30/24 18:42, Jonathan M Davis wrote:
> On Tuesday, April 30, 2024 7:43:52 AM MDT Timon Gehr via dip.development
> wrote:
>> 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 don't see why not. You shouldn't be able to mutate them, but reading them
> should be fine, since they're not going to change.
> 
>> I'd expect `shared(int)` bitfields are not allowed?
> 
> There should be no problem with shared bitfields existing. However, it
> shouldn't be legal to read them or write them so long as they're shared. But
> with the preview switch to lock down shared, that's true of any type,
> including int. Accessing shared data while it's not protected is always a
> problem.
> 
> Atomics shouldn't work with bitfields, since they can't, whereas if you
> protect them with a mutex, you can then temporarily cast away shared and
> operate on them just like you'd do with any other shared data. So, I don't
> see why bitfields would be at all special with regards to what needs to
> happen with shared.
> 
> - Jonathan M Davis
> 
> 
> 

Well, I am bringing it up because the DIP draft ignores type qualifiers 
so far (and explicitly only lists unqualified types for support). What 
is happening with `shared` I think has not been fully pinned down, but 
last I heard the goal was to get implicit atomics.