Extended Type Design.

[Frits van Bommel]

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> 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.

Ah, so I /did/ read that right.

>  >> (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 only benefit (albeit 
> a considerable one) of this nomenclature is compatibility with C++ 
> nomenclature, especially the term "const correctness".
> D currently has a 'const' which actually means "constant", it seems 
> dreadful to exchange that for a clearly inferior "don't touch" meaning.
> 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 agree with *that* :).

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

And I really hope this is not the case.

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

I don't see how this would be a surprise for anyone coming from C++. 
This is exactly how 'const' works for value types, isn't it? (Do this 
with reference types on the other hand, and I could see them being a bit 
confused)

The thing to keep in mind is that 'b' is a new variable (kept on the 
stack) that happens to have the same value as whatever was passed to the 
function. If that variable happens not to be changed by the code where 
it's in scope, that doesn't effect other code in any way at all.
In other words: There's no way to tell the difference from outside of 
the function, so why would it change the signature?