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).

Reply via email to