Extended Type Design.

Don Clugston dac at nospam.com.au
Wed Mar 21 07:50:58 PDT 2007


Andrei Alexandrescu (See Website For Email) wrote:
> Don Clugston wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> I think there's universal agreement that you can't express tersely 
>>> the two notions "const-as-in-C++" and 
>>> "const-as-in-we-really-mean-it". Probably it's best to just go with 
>>> two terms and move on.
>>
>> I completely agree with this. The gripe I have is that 'const' is a 
>> completely inappropriate term for 'const-as-in-C++'. It's a bizarre 
>> misnomer to use 'const' to mean "don't touch".
> 
> The problem is that we don't have a "nomer". Every good short name we 
> considered would be as imprecise or more. There's no obvious choice that 
> everybody's like, "those idiots! why did they _refuse_ to do it that 
> way?" And it's telling that every single person who didn't like "const" 
> with the intended meaning failed to come with an obviously better choice.

Actually, I have not tried to come up with a better choice.
I still think 'readonly' captures it pretty well. I've changed my mind 
about the validity of the argument about "it's not obvious which means 
truly constant, 'const' or 'readonly'" since I feel that it applies just 
as strongly to 'const' vs 'invariant'.
My intuition would be that 'invariant' means read-only. The usage of 
'invariant' in design-by-contract is for something that can be modified 
temporarily but must ultimately be preserved; this is weaker than 
'constant'.

>> The only benefit (albeit a considerable one) of this nomenclature is 
>> compatibility with C++ nomenclature, especially the term "const 
>> correctness".
> 
> Right. Imagine us coming with the "dontouch correctness" :o).
> 
>> D currently has a 'const' which actually means "constant", it seems 
>> dreadful to exchange that for a clearly inferior "don't touch" meaning.
> 
> It's not "inferior". If it were inferior, we'd take it out of the 
> language. Today's "const" semantics are restrictive in ways that 
> severely limit its usefulness (e.g. you can't pass data modifiable in a 
> module to functions guaranteed to NOT modify data in another module).
> The new const will allow that, and that's great. It's not inferior.

I'm arguing about the name, not the semantics. The use of 'const' in the 
original post has caused no end of confusion, since it is different from 
the current D const.
To rephrase:
'const' is a very appropriate word for what 'const' does in D now: it 
defines a constant. The proposed const has an inferior connection to the 
word 'constant'.

Actually, there's a feature of the existing const which seems to be 
missing in the new proposal.

Currently, if you have
const int x = 4;

it is illegal to write &x. (just as it is illegal to write &4).
This means that the existing const cannot be subverted, even by asm 
code. (#define x 4 is similar, except untyped). Can you do this with the 
new proposal?


>> I'm concerned that you may have spent so much time in C++ that you've 
>> become accustomed to "const" == "don't touch"; all of my previous 
>> posts have been arguing that this is a grossly unnatural association.
> 
> I completely hear you. Yet you are failing to follow with, "...when it's 
> so obvious to everyone that the natural association is..."

The natural association is "const" == "never changes, under any 
circumstances". "readonly" == "don't touch".
Even for read-only memory, if you've ever used an EPROM burner, or 
flashed firmware, you know that someone can write to it. I've changed 
readonly memory, I've never changed a constant.
The concept of 'read-only' access is pretty widely understood.




More information about the Digitalmars-d mailing list