Manifest constants (was const again)

[Bill Baxter]

Walter Bright wrote:
> Jérôme M. Berger wrote:
>>     I've always thought that "static" was a poor keyword for
>> what it does. As for the others, your argument doesn't stand:
>>
>> class
>>     A class of people or things is a number of people or things that
>>     are considered together because *they have similar
>>     characteristics*
>>
>>     It is therefore natural to define a class by the "similar
>>     characteristics" of its instances;
> 
> I'll concede that one.
> 
>> extern (short for "external" or "externally")
>>     Happening, coming from, or existing outside a particular place
>>     [...]
>>
>>     That is precisely what happens with most "extern" identifiers:
>>     they exist outside the current source file. From there, it is
>>     not too stretching to use the "extern" keyword to define how
>>     public identifiers will behave as seen from the outside;
> 
> How does that fit with extern(C) ?

What's the confusion?  In that case you're declaring something that uses 
an externally defined calling convention, that defined by C.  The 
calling convention is something outside the realm of that which is 
defined by D.  There's no trouble with it linguistically.

>> long (short for "long int")
>>     Long is used when giving information about the length of
>>     something [...]
>>
>>     Again, this is very descriptive of what a "long" is.
> 
> Ask someone who is a programmer, but not a C programmer, what a "long" 
> is, and they will have no idea.

That's not the point.  The point is if you explain the etymology of the 
use of long to a non-C programmer it will make sense to them.  Ok, long 
as in long number stored using a longer string of bytes than a normal 
integer.  The original meaning still makes sense applied to the 
programming use.  Which is not at all the same thing as saying that it 
completely explains and characterizes the programming use.

>>     However, the dictionary definition for enumerate doesn't fit
>> for a single value:
>>
>> enumerate
>>     When you enumerate a *list* of things, you name each one in
>>     turn.
> 
> A list of one is still a list. My dictionary defines enumerate as: "to 
> name one by one". That certainly fits:
>     enum X = 3;
>     enum Y = 4;
> as I'm naming X and Y one by one. At least it fits as well as the other 
> keywords do.

So why don't we use array syntax to define all variables?  A single 
variable is just an array of one, after all.  Ok, I know why, but still 
that seems to be the sort of argument you're making there.

> 'virtual' should also be added to the list of keywords that have no 
> connection to their dictionary meaning.

It doesn't seem so inappropriate to me.  "Virtual" is used in optics to 
describe images that you can see but aren't really there .  That sort of 
meaning was borrowed for computer memory.  A virtual memory is one you 
can use as if it were really there.  A virtual method is one that you 
can call as if it were really there.   Sort of.  Anyway what other word 
would you use to describe virtual methods?  There's no real good word 
for it.  Maybe "polymorphic" would have been better.  I don't think 
Stroustrup had any particular constraints that forced him to pick 
"virtual", so I suspect he probably has a pretty good rationale for 
using that word.   It's probably in his big book about the design of C++.

Anyway, at the end of the day a finding precedents for poorly-named 
keywords in programming languages does not justify creating more of them.

--bb