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

[claptrap]

On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
> On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:
>
>> Seriously how it's implemented is irrelevant.
>
> And to be clear, my point wasn't about how it's implemented. My 
> point was that:
>
> enum { foo = 10; }
>
> and
>
> enum foo = 10;
>
> Are effectively the same thing, whether it's implemented that 
> way or not. So why on earth would a new keyword be necessary?

Because they are not the same thing, one is a set of things, one 
is a single thing. That you say they are "effectively the same" 
is what Im getting at, just because they can be implemented the 
same, or one feature can be repurposed to serve the other need, 
doesnt mean they should. It's like...

int x;
int[1] x;

They are effectively the same thing, a single int on the stack if 
declared locally, but they are conceptually different. And to me 
programming is not just about getting the job done but about 
being able to express the concept / design precisely.

For example, this to me is utter nonsense...

enum auto isTwoWayCompatible(alias fn, T1, T2);

It makes about as much sense as using "enum" in place of "struct".

If enum means manifiest constant, or compile time constant, then 
it makes more sense, as you allude to in a later post. But 'enum' 
is a terrible name for that and I dont think my brain will ever 
stop finding it incongruous.