bit-level logic operations on enums

[Era Scarecrow]

On Saturday, 2 March 2013 at 00:36:19 UTC, Steven Schveighoffer 
wrote:
> Read the spec, carefully.  It's implemented as designed.
>
> http://dlang.org/type.html
>
> Implicit conversion: "A enum can be implicitly converted to its 
> base type, but going the other way requires an explicit 
> conversion."
>
> But for integer promotion:
>
> "If a enum has as a base type one of the types in the left 
> column, it is converted to the type in the right column."
>
> The left column referred to does not have anything 32-bit or 
> above in it besides dchar.  Remember that.
>
> Later on, regarding arithmetic operations:
>
> If one or both of the operand types is an enum after undergoing 
> the  conversions, the result type is:
> * If the operands are the same type, the result will be the 
> (sic) that type.
> * If one operand is an enum and the other is the base type of  
> that enum, the result is the base type.
> * If the two operands are different enums, the result is the 
> closest base type common to both. A base type being closer 
> means there is a shorter sequence of conversions to base type 
> to get there from the original type.
> Note that if no integer promotion occurs (I.e. base type is 32 
> bits or above and not dchar), and you are adding A with A, both 
> operands are of the same type, so "the result will be that 
> type."

  I've heard more than once the spec changing to fit an 
implementation. Still seems wrong.

  The enum's converted (not promoted) to it's numeric version and 
cannot be converted back. The details quoted are regarding 
integer promotion. If it's intended to be that way (enums + 
math/binary operators = same enum type) then the spec is flat out 
wrong.

  Following the simple logic and feature for 'final switch' that 
it's guaranteed to handles ALL cases and combinations of what the 
enum could be (thus there's no default); but it can't handle the 
cases presented.

  An enum (unless forcibly cast) should always be valid; So 
anything that could potentially modify the enum can only result 
in it's base type.

> Just bad design IMO.  It should be fixed.

  Agreed, needs to be fixed.