When bit fields are used to define bit protocols etc., they sometimes have constant fields, or already initialized variable fields. So It can be positive for std.bitmanip.bitfields to support that too, this is an example: field1 : 1; field2 : 2 = 0b01; immutable field3 : 3; immutable field4 : 4 = 0b1110; As with normal immutable fields in structs, the language has to forbid the write on immutable fields. Probably in many cases the compiler can't enforce this at compile time on bit fields (because of the type system granularity; something similar happens with pointers to single bits in bit-arrays), so probably the bit field immutability needs to be enforced at run-time (maybe even in release mode too, because it's a hard constraint).
See also bug 4937
Another possible feature is to make std.bitmanip.bitfields generate two versions of the code, that get compiled conditionally according to the CPU endianess: static if (std.system.endian == std.system.Endian.BigEndian) { ... } else { ... }
Adding const to a field seems pretty easy; specifically the setter is simply left out of the template. So as a final proposed usage, it would look like: mixin(bitfields( int, "named", 4, const int, "c_named", 4, uint, "named_def=5", 4, //includes defaulted value of 5 const uint, "c_named_def=10", 4)); //defaulted value of 10 bitfieldsOn is being worked on, and effectively works identically to bitfields except you specify a variable you want to use; Default values won't work well with it however.
(In reply to comment #3) > Adding const to a field seems pretty easy; specifically the setter is simply > left out of the template. OK. > So as a final proposed usage, it would look like: > > mixin(bitfields( > int, "named", 4, > const int, "c_named", 4, > uint, "named_def=5", 4, //includes defaulted value of 5 > const uint, "c_named_def=10", 4)); //defaulted value of 10 Good. And what do you think about facing the endianess problems (Comment 2)? > bitfieldsOn is being worked on, and effectively works identically to bitfields > except you specify a variable you want to use; Default values won't work well > with it however. What's bitfieldsOn?
I don't see any actionable item here, just some ideas. The situation have changed quite a bit since this issue was created: In particular, `static immutable` field do not occupy space in aggregates anymore, so the idea of having a CT-known `immutable` field means that it would likely be decoupled from the runtime one. As a result, closing as WONTFIX.