Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> Assuming that 'invariant' = really constant, 'const' = C++ 
>>> pseudo-const...
>>
>> Yah.
>>
>>> It's better than super const. However:
>>> (1) I would want to go through all my existing D code and change 100% 
>>> of my usages of 'const' to 'invariant'.
>>
>> Great to hear that!
> 
> Sorry, I didn't explain myself very well. I meant that this proposal 
> breaks 100% of all existing D uses of const.

I don't think so. Const becomes less precise, but maybe code wasn't 
using it with all the precision anyway. I actually suspect the new 
semantics will break very little code.

>  >> (3) I concede the problem of association with 'readonly' and ROM. But
>>> the association between 'const' and 'constant' is pretty strong.
>>
>> 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.

> 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 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..."

> It is possible that the C++ misnomer is so entrenched that D needs to 
> perpetuate it, even at the expense of breaking all existing D code that 
> uses 'const'.
> But then this really surprises me:
> 
>> final int a = 2;
>>
>> void f(final int b)
>> {
>> }
>> The choice of "final" in the second case prevents f from changing its 
>> argument,
>  > and it's the free will choice of f's author. The "final" does not
>  > influence f's signature or how other people use it.
>  > It's just constraining f's implementation.
> 
> because it seems that that we still have 'const' surprises for C++ 
> refugees.

We can make "const" mean "final const" and drop "final", at the cost of 
disallowing correct code (e.g. functions that modify their own private 
parameters). Or we could come up with new syntax that puts "const" in a 
different position for array, e.g.:

void Fun(const char[] const s);

After considering such alternatives, final becomes much more attractive.


Andrei