Manifest constants - why not 'alias' ?

[Walter Bright]

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?

> So there you have it, Walter: Unanimous support on this newsgroup
> (...is that unprecedented?...) for NOT using enum as a storage class
> to define compile-time constants.
> 
> We all seem to be cool with the concept, just not with the word
> "enum". My fave is "final", but I'd be happy with any of the other
> alternatives that have been suggested so far.

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;
	}
? 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? Why does:
	final int x = 3;
make any more intuitive sense than:
	enum int x = 3;
? And lastly, since anonymous enumerated constants are already just what 
we need, and the proposed new enum variation is just a syntactic 
shorthand for an anonymous enum with one member, what is the intuitive 
argument for when one should use a final and when one should use an enum?