If you didn't know, bitfields just landed in the latest beta!

https://dlang.org/changelog/2.101.0.html#dmd.bitfields

Definitely a huge improvement over the current way of doing bitfields (import module + template) (in my opinion)

However, in his blog, adam has some interesting concerns about it, and shared a proposal on how it could be made better

I personally like his proposal, i would love to hear what Walter thinks about it!

It takes what C offers, and make it safer to use! it's exactly a BetterC language!

(btw, we could do the same for tagged union and .enum ;) ;) ;) ;) ;) ;) ;), just dropping this idea here)

Here is the link of adam's blog post: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_09_12.html#d-bitfields-could-be-good

On Tuesday, 18 October 2022 at 19:11:35 UTC, ryuukk_ wrote:

As I said in the other thread, I think we need both. Both extern(C) bitfields to match what C is doing and D bitfields that can actually be good and portable across different systems/ABIs.

On Tuesday, 18 October 2022 at 19:11:35 UTC, ryuukk_ wrote:

The syntax Adam proposes is this:

ulong fields {
      msb : 1,
      _reserved: 62,
      lsb: 1,
};

Personally, I don’t like the idea of taking the syntax Type Identifier { } for something as niche as bit fields. If we ever move to properties à la C#, this will close a door. And it will close it unnecessarily. The fix is rather easy: Remove the name:

ulong
{
    msb: 1; // semi colon
    _reserved: auto; // auto (allowed at most once) = ulong’s bits minus given bits.
    lsb: 1;
} // no semi colon

It still should have a auto-generated name for the allMembers trait. If you want a name, use an anonymous union:

union
{
    ulong bitfields;
    ulong
    {
        msb: 1;
        _reserved: auto;
        lsb: 1;
    }
}

On Tuesday, 18 October 2022 at 21:07:51 UTC, Dave P. wrote:

extern(C) bitfields could be very userful when you need translate c to d