"Andrei Alexandrescu" <[email protected]> wrote in message news:[email protected]... > On 03/25/2010 09:38 PM, Nick Sabalausky wrote: >> "Andrei Alexandrescu"<[email protected]> wrote in message >> news:[email protected]... >>> On 03/25/2010 02:52 PM, Nick Sabalausky wrote: >>>> >>>> I can agree mixins are a perfectly fine interim solution for anything >>>> not >>>> already in the language, and for truly obscure needs (I use them all >>>> the >>>> time for both situations myself). But I'd still hardly consider flags >>>> and >>>> bitfields (to be clear, I'm talking about the abstract concept of a >>>> bitfield >>>> in general, not necessarily the C-style >>>> struct-with-sub-byte-member-alignment bitfield syntax/semantics) to be >>>> an >>>> "obscure" need in something that's supposed to be a systems language. I >>>> guess we just have a fundamental disagreement on that. >>> >>> In what ways do you find the bitfield interface wanting? >>> >> >> Ignoring frequency-of-usage for the moment, since this is a question of >> syntax, compare these two syntaxes of creating a struct: >> >> mixin(struct!("myStruct" >> uint, "x", >> int, "y", >> uint, "z", >> bool, "flag")); >> >> Versus the current: >> >> struct myStruct { >> uint x; >> int y; >> uint z; >> bool flag; >> } >> >> There's just less syntactical noise, and the syntax is designed around >> the >> semantics rather than shoehorning various generic syntaxes to fit the >> purpose. > > But frequency of usage is essential. This is about bitfields, not struct. > The former are arguably much less used than the latter. And then, there > are many more uses than definitions. >
The question was "In what ways do you find the bitfield interface wanting?" I gave you my answer (syntactical noise and the syntax isn't designed around the feature but rather takes other syntaxes and shoehornes them in to fit the purpose.) That is the fault I find with it. Regardless of how common or uncommon it is, I still find that fault with it. Now certainly, if something is an rare enough need, than I can accept a certain amount of fault in the syntax. But that still doesn't change the syntax's faults. They're still there, they just may or may not be forgivable. If structs were a super-duper rare need, then I could live with the "bad" struct syntax above even though it clearly has faults. Maybe I didn't make this clear before (and I apologize for that), but anytime I've talked about bitfields being a common need, I've been talking about the abstract concept of a bitfield in general, not necessarily std.bitmanip.bitfield. I've been in D1/Tango-land for all of my D development lately, so I have to rely on the docs for my knowledge of std.bitmanip.bitfield. And the docs for std.bitmanip.bitfield don't appear to say anything about them other than just simply the syntax for how to create one (I can see that now that I realize the bitarray documentation is unrelated). So, to be clear: I have no idea whether or not I would find std.bitmanip.bitfield suitable enough for a large enough portion of the general bitfield uses out there (ie, to replace typical uses of manual bit-twiddling with ANDs, ORs, and bitmasks) that I would consider it as common a need as bitfields in general are. Bitfields in general: Very common need for systems programming, just ask Walter how many times he's ANDed or ORed a bitmask in his career. Phobos's 'std.bitmanip.bitfield': I have no idea how common the need.
