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