enum and const or immutable ‘variable’ whose value is known at compile time

[Mike Parker]

On Thursday, 17 September 2020 at 13:13:46 UTC, Simen Kjærås 
wrote:

>
> To quote Bill Baxter from way back when
> (https://forum.dlang.org/post/fjdc4c$2gft$1@digitalmars.com):
>
>> > Why does:
>> >     final int x = 3;
>> > make any more intuitive sense than:
>> >     enum int x = 3;
>> > ?
>> 
>> There are these things called "words".  And they have 
>> "meanings"...
>> enum: (short for "enumeration", the noun form of "enumerate")
>>    "to specify one after another : list"
>> final:
>>    "not to be altered or undone <all sales are final>"
>
> To be clear: I don't mind 'enum' being used this way, but if I 
> were to do things over again, I would have used 'alias'.
>

Well, I was already using anonymous enums for compile-time 
constants anyway. For example, when translating C headers with 
lots of #defined constants (OpenGL is the poster child), I was 
doing this in Derelict:

enum {
    GL_THIS = ...,
    GL_THAT = ...,
}

So enum for this has always made sense to me. I would have been 
fine with final, but it would have been a leap for me because of 
my Java background; I would have kept seeing it as a synonym for 
const. And I would never have liked the Alias approach.

But no matter what solution would have been implemented (final, 
Alias, new keyword), I would have looked it up then, put my head 
down and gotten right back to writing code. It just happens the 
one that's most intuitive to me was picked :-)