D const design rationale

[Bruno Medeiros]

Oskar Linde wrote:
> 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

I *highly* agree. As explained by Oskar, 'readonly' is a way better 
description for D2.0's const than 'const'. It is not just a "better" 
description, it is a more *accurate* and *correct* one. The only reason 
we have this concept named 'const' in D is pure C++ legacy mentality, as 
D's mutability system (final-const-invariant) was designed from C++ 
mutability system(just const). However, since D's mutability system is 
so different from C++'s, Walter, why would you want to maintain the 
'const' keyword and not change it to something better?
Walter, please consider these arguments.

PS: If one wants a shorter alternative than 'readonly', I think the 
shorter 'rdonly' keyword would rapidly, and as easily, be assimilated by 
our programmer minds to represent the read-only concept.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D