Thread overview
Bitfields in D
Oct 18, 2022
Dave P.
Oct 18, 2022
zjh
Oct 18, 2022
test123
October 18, 2022

Adding bitfields to D for C interop is nice as it will automatically match the platform’s ABI for bitfields, but I don’t understand why we would want the implementation defined nightmare for regular D bitfields. One of the most annoying things about C bitfields is that if you use them, you can’t just write your structs to disk or across the network as your format is immediately non-portable across different systems. That sucks as that’s exactly when you would want to save space with bitfields. Native D bitfields should avoid this problem.

However, you should be able to express that your struct including bitfields matches the layout of a C struct. I therefore propose that we tweak the syntax to require an extern(C) around bitfields matching C.

struct A {
    extern(C) {
        int x:3, y:2;
    }
}

Or

extern(C)
struct B {
    int x: 3, y:2;
}

And then have bitfields that aren’t extern(C) be illegal until the semantics are worked out. For example, Adam’s ideas could be good.

October 18, 2022

On Tuesday, 18 October 2022 at 03:04:52 UTC, Dave P. wrote:

>

[Adding bitfields to D]

For me, the more features, the better.

October 18, 2022

On Tuesday, 18 October 2022 at 03:04:52 UTC, Dave P. wrote:

>

Adding bitfields to D for C interop is nice as it will automatically match the platform’s ABI for bitfields, but I don’t understand why we would want the implementation defined nightmare for regular D bitfields. One of the most annoying things about C bitfields is that if you use them, you can’t just write your structs to disk or across the network as your format is immediately non-portable across different systems. That sucks as that’s exactly when you would want to save space with bitfields. Native D bitfields should avoid this problem.

[...]

With d CTFE reflection, this is easy to workaround.