Manifest constants (was const again)

[Walter Bright]

Bill Baxter wrote:
> Is there some reason why it matters what alias currently does?

Yes, because it usually isn't a good idea to use it for something 
different but confusingly similar.


> I think 
> this is why most people here are disagreeing with you about using 
> "enum".  You seem to be looking from the language implementer's point of 
> view and saying "which chunk of code do I have already implemented that 
> would be easiest to change into something supporting manifest 
> constants?".

No, none of these schemes is particularly harder than the other to 
implement.

> Whereas most of us are looking at the *words* and saying 
> "which of these words best describes what we're trying to do?"

Keywords in programming languages often only have a remote semantic 
connection with their dictionary meaning, and sometimes none at all. But 
this still works because our brains are pretty good at switching into, 
say, "C mode" when reading C code, and we have no problem understanding 
that 'static' in one context means a member function without a 'this' 
pointer, while 'static' in another context means the variable is 
allocated space in the data segment rather than the stack segment. 
Neither definition is in the dictionary. I could argue similarly for 
'class', 'extern', 'long', etc.

What is appealing about enum is it is already used to declare manifest 
constants, and it is certainly already comfortably used to declare 
manifest constants that aren't "enumerations" in a dictionary sense of 
the word. My proposal is only a minor extension to an already existing 
use of the keyword, and I believe it is much less of a stretch than, 
say, using 'final'.


> Supporting  alias int x = 3  may be more difficult to implement than 
> enum int x = 3  because it changes the role of alias.

It is not more difficult to implement. But I do suggest it is more of a 
cognitive load, because it becomes harder to remember that:
	alias X Y;
and:
	alias X = Y;
are not only very different, but the *order* of the operands is 
reversed! This is a much more serious issue than I think it is given 
credit for. For example, gcc's inline assembler syntax has the operands 
reversed from Intel's assembler syntax. It is hard for me to explain how 
difficult this makes it for me to use gcc's inline assembler. If I use 
it for a while, I find myself staring at assembler code in complete 
non-comprehension. It's so bad that I refuse to write it any more.

With the enum case, I doubt it would take more than a moment for someone 
to figure out what it was, and it is not confusingly similar to 
something else. Once one knows what it is, one might take a moment to 
ridicule the choice of keyword, but that's about it before getting past 
it and it becoming just more D jargon like static, class, and real.