D const design rationale

[Oskar Linde]

Walter Bright skrev:
> Oskar Linde wrote:
>> Walter Bright skrev:
>>> OF wrote:
>>>> Walter Bright Wrote:
>>>>
>>>>> BLS wrote:
>>>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>>>
>>>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>>>> represent :
>>>>>> invariant, final, readonlyview.
>>>>>> the higher the number the higher (the stronger) the const.
>>>>>> means : const_3 == invariant;
>>>>>> At least a mental help, IMO; somehow borrowed from Modula 2 
>>>>>> processes.
>>>>> You're right, I don't like the idea <g>.
>>>>
>>>> I'm curious. Was 'readonly'
>>>
>>> readonly is a synonym for const, so no improvement there.
>>
>> Read-only isn't synonymous with constant.
> 
> Consider ROM, i.e. "Read Only Memory".

Yes, there are cases where the meaning of read-only and constant 
overlap. You could even argue that the overlapping meanings are large 
enough to make the words synonymous, but that is irrelevant to the 
discussion.

What is relevant is which word does best describe the properties the 
D2.0 'const' has? IMHO, read-only wins by a large margin. Read-only 
describes everything 'const' is, while the generally accepted meaning of 
constant is a poor fit.

This has been irking me for quite some time, and I believe it is the 
reason the final-const-invariant thing feels so awkward (to me). The 
design has been carefully considered and is quite likely the best 
possible given the requirements. However, the use of "const" to mean 
read-only sticks out like a turd in a punch bowl (pardon the expression).

People argue that of the different meanings of "const" in C++ (that you 
like to point out), the non-constant meaning is the worst and most 
confusing. Still, the only meaning for "const" that D inherit from C++ 
is that one.

<parenthesis>
I've never heard anyone complain about "const" as a "storage class", 
like in:

const double e = 2.7182818284590452354;
const double pi = 3.14159265358979323846;
<parenthesis>

I believe *many* people would be *much* less confused and have a *much* 
easier time acceping and grasping the D const behavior if better 
keywords were used. "What? Const means it can change???"

So I plead: Please reconsider the keywords. The implications of not 
doing that are severe. The publics acceptance of D is at stake.

What if you could say, "Look: We fixed C++'s const. Const now really 
means constant -- not could-actually-change and you will be damned if 
you assume anything else". This is a hypothetical scenario of changing 
final-const-invariant -> final-readonly-const. There could possibly be 
even better choices of keywords.

Apologies for being so harsh (and hyperbolic), but I feel this is (as 
strange as it may sound) a quite important issue.

/Oskar