https://github.com/WalterBright/documents/blob/master/bitfields.md

"gdc/lcd are lumped together because they produce identical results on the same platform."

s/lcd/ldc/

No mention of alignment, total size or the offset.

Needs to mention atomics as not being supported.

No trait to detect a bit field (if its an alias, or by name), nor get its size. Kinda required, enough other things in the language can appear via an alias sequence or by allMembers that are not able to be taken as a pointer of.

The ability to take an alias via getMember needs to be considered if its valid to do so.

No mention of tupleof either, what happens there?

No motivation for not including a D layout for it, instead of forcing everyone into an unpredictable layout that the system C compiler might be using. Moving us off the library type and into a language defined one that is predictable is quite attractive so there needs to be an argument against this.

Also both the post and its subject do not match the guidelines for this forum. So I'm half wondering if it's even worth writing this post knowing that Mike could delete it.

https://github.com/dlang/DIPs/blob/master/docs/guidelines-forums.md#dip-development

On 3/7/2024 4:04 AM, Dennis wrote:
> On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:
>> https://github.com/WalterBright/documents/blob/master/bitfields.md
> 
>> I've seen plentiful use of it, and have not seen any "do not use bitfields" programming guidelines.
> 
> [Bit-fields in C have acquired a poor reputation in the programming community](https://andrewkelley.me/post/a-better-way-to-implement-bit-fields.html)

All Zig is doing is providing a slightly different syntax that does the same thing as C. Zig is layering on a magic "pointer to bit field type" that I attempted to implement in D long ago, but it has too many special cases and turned out to be unworkable. You cannot convert a pointer to bit 3 to a void*, making the special bit pointer type rather useless.


> [C bitfields considered harmful](https://www.flamingspork.com/blog/2014/11/14/c-bitfields-considered-harmful/)

I don't know of any C compiler that puts a single bit flag in a 64 bit int. He didn't show enough code to see the source of his problem. I suspect he doesn't know what he's doing.


> [So don't go for bitfields "just because"](https://yarchive.net/comp/linux/bitfields.html)

Linus suggests using explicit bit masks instead.


> [Bitfields seem to be perfect for this, but they're so poorly specified in the standard that common "best practice" is to avoid them.](https://www.reddit.com/r/C_Programming/comments/146tbnp/why_is_using_bitfields_in_high_performance/)

I.e. the layout is implementation-defined. That's correct. But in reality, it is fixed. There is no way that gcc on Linux is *ever* going to change the bit field layout, because it would break legions of existing code. It is cast in concrete, and is as immutable as it gets. The same for Microsoft C.

Furthermore, if you use `int` as the base type for bit fields, the layouts are all the same in all the C compilers I've encountered. For practical purposes, it is defined.

If you are still concerned about the layout, like you want a portable file format, don't use bit fields. Use std.bitmanip.

But if you want to be compatible with C code that uses bit fields, the builtin bit fields are the way to go.

If you like a nice syntax, bit fields cannot be beat.

If you want to pack data in your structs and use less memory for your program, bit fields are again a winner. DMD uses far too much memory. Much of the data structs it uses can be packed, but since without bit fields the syntax is just too ugly, there's been little effort to do that. Convenience is everything.

If you still don't like bit fields, don't use them.

And yes, you can't do volatile, shared, atomic, or pointers to bit fields. You can't do those with std.bitmanip, either. Nor can you do them with manual masking and shifting.

On Thursday, March 7, 2024 3:28:34 PM MST Dennis via dip.development wrote:
> Why bow down to C and treat D as a second class citizen? The DIP should really substantiate this alleged importance of C-compatibility of non-ImportC D bitfields: Can you name at least one dub package that would benefit from bit fields with C-compatible layout?

Having the ability to declare C-compatible bitfields would definitely be useful for binding some C symbols. I was recently dealing with some symbols on Windows where I basically had to skip the bitfields when writing the bindings, because I don't know of any way to bind to them in D.

That being said, I see no reason for bitfields for actual D code to be C-compatible. Unless I'm actually binding to a C type, C-compatibility is irrelevant, and if what C is doing isn't portable, then why would I want it for my D code?

- Jonathan M Davis

The inconsistency of C bitfield layout is far less important than it is made out to be. Other inconsistencies C has: char/short/int/long sizes, float/double/longdouble behaviors, 1s or 2s complement arithmetic, field alignment and endianness. Even the signed-ness of chars is implementation-defined. D matches that behavior of the associated C compiler. Living with that is normal.

The gdc and ldc backends are written in C++. D bitfields would enable bitfields to be used in the D front end, and the backends can use them effortlessly (should be no problem for dtoh).

An important feature of D is interoperability with C (and to some extent C++). Reducing the friction as much as we reasonably can will lower the barriers to D adoption. It means D code can co-exist peacefully in the same binary. When gdc and ldc are ported to a different platform, with different C bitfield layouts, it will still *effortlessly* work correctly.

I like effortlessly.