Extended Type Design.

Sean Kelly sean at f4.ca
Mon Mar 19 11:44:29 PDT 2007


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!

Great perhaps, but it does suggest that 'const' should perhaps be the 
signifier for what 'invariant' has been proposed for (the literal 
meaning of each term notwithstanding)?

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

invariant int* x;
int* y;

void fn( const int* z ) {}

fn( x );
fn( y );

Assuming the above is legal, 'const' is the qualifier which binds to all 
reference types, ie. "to match a non-const value, you use 'const'."

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

It's too bad too, since this word makes the most semantic sense :-)


Sean



More information about the Digitalmars-d mailing list