Manifest constants - why not 'alias' ?

[Bill Baxter]

Walter Bright wrote:
> Janice Caron wrote:
>> On 12/7/07, Leandro Lucarella <llucax at gmail.com> wrote:
>>> That's the worst reason ever! There are so many things we already use 
>>> that
>>> sucks...
>>
>> Yep, I agree with everyone. Especially with the above comment. I will
>> certainly /stop/ writing enum { x=3 } if a more intuitive way comes
>> along.
> 
> Why isn't:
>     enum x = 3;
> more intuitive?

Because you're *not* *enumerating* anything.

 From wikipedia:
"""
In computer programming, an enumerated type is an abstract data type 
used to model an attribute that has a specific number of options (or 
identifiers) such as the suit of a playing card (i.e. a Club, Diamond, 
Heart or Spade). Using this type allows the program to handle the 
attribute more efficiently than a string while maintaining the 
readability of the source code.
"""


> Let's look at final for a moment. Final is currently a storage class for 
> member functions, as in:
>     final
>     {
>         int foo();
>         int bar();
>     }
> but yet:
>     final x = y;
> is proposed. This doesn't work too well in the syntax, as we don't have:
>     typedef
>     {
>         int myint;
>     }
> either, would we really want:
>     final
>     {
>         x = y;
>     }

Actually I kind of like that block typedef!  Often templated classes 
start off with a preamble of aliases.  It would be nice to put them all 
in a block.  (But it would be easier to read if it could be done with 
the x = y style, since "int myint" looks like it's declaring an integer 
variable).

> ? I don't think that looks right. alias also has strange syntactical 
> problems already discussed, like does:
>     alias int x = 3;
> make any intuitive sense? 

Sure! It means

   alias x = cast(int)3;

it's an alias for the literal 3 that you're specifying you would like 
the compiler to treat as an int.  But since it acts like a variable you 
can declare it using a variant of standard variable syntax.

> 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>"

(definitions courtesy m-w.com)

> And lastly, since anonymous enumerated constants are already just what 
> we need, 

Enumerated constants are *not* what we need.  We need manifest 
constants.  We're not enumerating anything!  We're just trying to 
declare shorthand name for a constant value.

> and the proposed new enum variation is just a syntactic 
> shorthand for an anonymous enum with one member, 

That's the only thing using 'enum' has going for it.

> what is the intuitive 
> argument for when one should use a final and when one should use an enum?

The description in wikipedia is decent:
http://en.wikipedia.org/wiki/Enumerated_type

C's enumerated types already bastardized the concept a bit by allowing 
specific values to be assigned.  D goes further in some ways by allowing 
you to specify a type for the enum as well.  And this new proposal is 
like the nail through the heart of any vestigial meaning remaining in 
the word 'enum', either mathematical or layman's.

--bb