Manifest constants - why not 'alias' ?

[Janice Caron]

On Dec 7, 2007 2:36 AM, sambeau <please-dont-spam-sambeau at mac.com> wrote:
> This all makes sense as an implementation, but not as a language design.
> You need to step back and look at the word 'enum' and ask yourself does it make sense?
>
> Surely, if you are proposing to change the use of 'enum' in this significant way you should change it's name. Otherwise everyone will be confused.
>
> Def, let, constants, defines,  ... , etc
>
> They all have two advantages
> 1) they sound like what they do
> 2) they aren't a reuse of something that already does something

That makes sense.

>From a purely /conceptual/ point of view, "true" enums shouldn't have
any numerical value at all - just a successor/predecessor
relationship. That is, one can imagine (in a different language)

     enum Month { January, February, March, April, May, June, July,
August, September, October, November, December };

     Month m = Month.February;
     Month n = m.successor();
     if (n > m) { /*...*/ }

without ever exposing the implementation, or the internally stored
value, which now matters only to the compiler.

However...

C did not adopt that model. Instead, C mandated that enums be
implemented as an int, and C++ copied C. D then copied C/C++, but with
the added feature that you get to specify the underlying type. So now
we've got what we've got, and either we stick with it (...in which
case I see no harm in either (a) allowing underlying types to be
non-integer, or (b) treating the braces as optional...), or we rethink
and start again.

We /could/ rethink and start again. We could define a new reserved
word (I'm going to use "meta", just for argument's sake) which means
"available at compile time". It could replace all current uses of
"const" and "static" for that purpose ("static if", CTFE, etc.). That
being done, one could then write

    meta int x = 3;

or just

    meta x = 3;

with type-deduction, to get a compile-time constant, and consistent
keyword usage. "enum" could then be retooled to act more like a "true"
enum should. Actually, I'd quite like that option. The problem is,
it's probably too great a breaking change. If it only broke D2 code,
no one would complain, but this would break D1 code as well. So, with
that bourne in mind, Walter's solution really isn't bad.