Implicit enum conversions are a stupid PITA

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hoh8eb$1kba$1 at digitalmars.com...
> On 03/25/2010 09:38 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
>> news:4BABC1F7.6080504 at erdani.org...
>>> 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.