Implicit enum conversions are a stupid PITA

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:hoepts$2a98$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> Custom bitfields are extremely useful for low-level code. Being a 
>> self-proclaimed "systems" language, there's no reason D should consider 
>> such a thing to be of "narrow-usefulness".
>
> I've written a lot of low-level code, I even programmed Mattel 
> Intellivision cartridges and one of those old 70's hand-held LED games 
> (Mattel Soccer). I've done a lot of embedded 6800 microprocessor work, 
> device drivers, graphics drivers, etc. I've done a lot of bit twiddling 
> code.
>
> But I find C bit fields to be generally worthless.
>
> One reason is the standard requires them to be right justified after 
> extraction. This kills performance. I muck with with them in-place using 
> biased arithmetic.

Actually, with "bitfields", I've been mostly referring to pretty much just 
that: doing manual bit-twiddling, typically aided by manifest constants 
and/or enums, and taking the stance that doing that could use a better (ie, 
more abstracted and more type-safe) interface (while still keeping the same 
under-the-hood behavior).

Maybe it's all the low-level stuff I've done, but any time I come across the 
term "bitfield" I instinctively envision those abstract rows of labeled 
"bit" squares (or differently-sized rectangles) that you see in spec sheets 
for digital hardware (ie, the abstract concept of a small piece of memory 
having bit-aligned data), rather than specifically the 
structs-with-sub-byte-member-alignment that I keep forgetting C has. I can't 
really comment on that latter kind as I've never really used them (can't 
remember why not), although I can easily believe that they may be 
insufficient for the job. Maybe that difference is where the disagreement 
between me and Andrei arose.