Bug 3999 and 4261

[Daniel Gibson]

bearophile schrieb:
> Daniel Gibson:
> 
>> Why not use the non-fictional const keyword? "The const attribute 
>> declares constants that can be evaluated at compile time."[1]
> 
> But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time.
> 

Really? Than that definition from the language docs is inaccurate.

> 
>> "enum int n = 10;" looks really strange. I don't know if this is needed..
> 
> I think it helps in a linker issue. But I am not expert on this. Maybe LDC (based on LLVM) doesn't need enums much.
> 
> 
>> But "enum : int { FOO, BAR, BAZ };" does not look so strange to me and 
>> I'd prefer this to "const int FOO=0; const int BAR=1; const int BAZ=2;".
>> The syntax is shorter, it shows that these keywords kind of belong 
>> together and the values are enumerated automatically.
> 
> I agree, and I have never said I want to disallow it. You can cast those FOO, BAR, etc implicitly to int. It's the example V2 I have shown, no error there:
> 
> enum V1 = 10;
> enum { V2 = 20 }
> enum Foo { V3 }
> void main() {
>     assert(V1 == 10);    // OK
>     assert(V2 == 20);    // OK
>     assert(Foo.V3 == 0); // ERROR, type mismatch
> }
> 
> Thank you for your doubts and questions, they help me express better what I meant. It seems I was not clear enough at the beginning.
> 
> Bye,
> bearophile

I know what you meant - but my point is that anon. enums make sense (I 
guess we agree on that one) and that allowing implicit casting to int 
for them and not for named enums seems inconsistent.
Of course disallowing implicit casting for anon. enums is not really an 
options (how should that even work.. maybe "cast(enum:int)foo" or 
something like that..) so IMHO a reasonable solution is keeping it the 
way it is.

Cheers,
- Daniel