An idea (Re: Implicit enum conversions are a stupid PITA)

[Don]

Walter Bright wrote:
> Nick Sabalausky wrote:
>> To put it simply, I agree with this even on mere principle. I'm 
>> convinced that the current D behavior is a blatant violation of 
>> strong-typing and smacks way too much of C's so-called "type system".
> 
> You're certainly not the first to feel this way about implicit 
> conversions. Niklaus Wirth did the same, and designed Pascal with no 
> implicit conversions. You had to do an explicit cast each time.
> 
> Man, what a royal pain in the ass that makes coding in Pascal. 
> Straightforward coding, like converting a string of digits to an 
> integer, becomes a mess of casts. Even worse, casts are a blunt 
> instrument that *destroys* type checking (that wasn't so much of a 
> problem with Pascal with its stone age abstract types, but it would be 
> killer for D).
> 
> Implicit integral conversions are not without problems, but when I found 
> C I threw Pascal under the nearest bus and never wrote a line in it 
> again. The taste was so bad, I refused to even look at Modula II and its 
> failed successors.
> 
> D has 12 integral types. Disabling implicit integral conversions would 
> make it unbearable to use.

I think there might be some low-hanging fruit, though.
Supposed we distinguished enums containing AssignExpressions from those 
which do not.
It seems clear to me that logical operations should always be permitted 
on enums where every member of the enum has been explicitly assigned a 
value.
enum Enum1 { A = 1, B = 2, C = 4 }
  ---> A|B makes sense.

But if there are no assign expressions at all:
enum Enum2 { A, B, C }
then I think that performing arithmetic on that enum is almost certainly 
a bug.

The case where only some of the enum members have assign expressions is 
less clear. Some cases, such as synonyms { A, B, C=B } aren't really any 
different from the no-assign expression case. But other cases are less 
clear, so I'll just ignore them all. So I propose a simple rule:

Suppose that implicit integral conversions (and arithmetic/logical 
operations) involving enums were permitted ONLY if the enum has at least 
one AssignExpression.

This would catch some bugs, without (I think) causing much pain for 
valid code. At the very least, this is something I'd want in a lint 
tool. (But note that it wouldn't fix the issue in the original post).