second draft: add Bitfields to D

Jonathan M Davis newsgroup.d at jmdavisprog.com
Tue Apr 30 16:42:52 UTC 2024


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





More information about the dip.development mailing list