I'm looking for D2 rough edges. I've found that this D2 code compiles and doesn't assert at runtime:


enum Foo { V1 = 10 }
void main() {
    assert(Foo.V1 == 10);
}


But I think enums and integers are not the same type, and I don't want to see D code that hard-codes comparisons between enum instances and number literals, so I think an equal between an enum and an int has to require a cast:

assert(cast(int)(Foo.V1) == 10); // OK


That has made me curious, so I've tried C++0x, and it seems in C++0x Foo::V1 == 10 gives a compile error ("enum class" is strongly typed enum of C++0x):


enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}


...>g++ -std=c++0x test.cpp -o test
test.cpp: In function 'int main()':
test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
test.cpp:3: note: candidates are: operator==(int, int) <built-in>

Do you think this is worth a bug report (with the "accepts-invalid" keyword)?

Bye,
bearophile

bearophile wrote:
> I'm looking for D2 rough edges. I've found that this D2 code compiles and doesn't assert at runtime:
> 
> 
> enum Foo { V1 = 10 }
> void main() {
>     assert(Foo.V1 == 10);
> }
> 
> 
> But I think enums and integers are not the same type, and I don't want to see D code that hard-codes comparisons between enum instances and number literals, so I think an equal between an enum and an int has to require a cast:
> 
> assert(cast(int)(Foo.V1) == 10); // OK
>

Spec explicity says enums are convertible to their base type:

http://www.digitalmars.com/d/2.0/enum.html

> 
> That has made me curious, so I've tried C++0x, and it seems in C++0x Foo::V1 == 10 gives a compile error ("enum class" is strongly typed enum of C++0x):
> 
> 
> enum class Foo { V1 = 10 };
> int main() {
>     int b = Foo::V1 == 10;
> }
> 
> 
> ...>g++ -std=c++0x test.cpp -o test
> test.cpp: In function 'int main()':
> test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
> test.cpp:3: note: candidates are: operator==(int, int) <built-in>
> 
> Do you think this is worth a bug report (with the "accepts-invalid" keyword)?

No. enum class is a specifc new feature of of C++ to prevent the implicit conversion. Might be worth requesting the feature for D, but changing the current behaviour of enum could be pain.

Besides, use of enums should be discouraged in general.
It sucks maintaining code where you've thousands of switch statements
all over the place; there's nearly always a better way.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0:

>Spec explicity says enums are convertible to their base type:<

Right, but I am not sure it's a good design decision. I think requiring a cast can be better.


>but changing the current behaviour of enum could be pain.<

In the meantime I have written an "enhancement" report (3999), but now I am not sure that I have done the right thing.


>Besides, use of enums should be discouraged in general.<

D enums are a significant improvement over long list of normal integer constant, as I see sometimes in C code. They are safer and nicer.


>It sucks maintaining code where you've thousands of switch statements all over the place; there's nearly always a better way.<

Unfortunately in D there are no computed gotos yet (even if gcc supports them and LLVM is starting to be able to manage them), and today D back-ends aren't able to inline virtual functions, so in some situations (final, in D2) they are the best solution I see in D. Sometimes I have to switch over many gigabytes of data.

Thank you for your answers,
bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:ho8k5m$5k3$1@digitalmars.com...
> div0:
>
>>Spec explicity says enums are convertible to their base type:<
>
> Right, but I am not sure it's a good design decision. I think requiring a cast can be better.
>

I absolutely agree.

>
>>Besides, use of enums should be discouraged in general.<
>
> D enums are a significant improvement over long list of normal integer constant, as I see sometimes in C code. They are safer and nicer.
>

Absolutely.

>
>>It sucks maintaining code where you've thousands of switch statements all over the place; there's nearly always a better way.<
>
> Unfortunately in D there are no computed gotos yet (even if gcc supports them and LLVM is starting to be able to manage them), and today D back-ends aren't able to inline virtual functions, so in some situations (final, in D2) they are the best solution I see in D. Sometimes I have to switch over many gigabytes of data.
>

Not only that, but there are many times when trying to use something other than switch/enum is just simply complete overkill anyway. If I were actively trying to avoid enum, I'd feel like I was using Java.