Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

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!

> (2) although (1) could be avoided with the rule that 'const' on a 
> declaration implicitly means 'invariant', this would then mean that to 
> match a 'const' value, you use 'invariant'; but to match a non-const 
> value, you use 'const'. That's horribly confusing.

This I don't understand. Could you give an example?

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

> The problem remains that in:
> 
> const int a = 2;
> 
> void f(const int b)
> {
> 
> }
> 
> a really is a constant, but there is nothing constant about 'b'!

The code is incorrect. Const and invariant refer to indirectly-addressed 
memory. Probably you mean:

final int a = 2;

void f(final int b)
{
}

The choice of "final" in the first case makes "a" bound to "2" for 
eternity. 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.

The two uses of "final" are reasonably consistent with one another.

> How about 'protected'?
> It seems to cover the 'don't touch' meaning pretty well...

class Foo {
   protected: protected char[] find(protected char[] haystack, protected 
char[] needle);
}

'Nuff said :o).


Andrei