Walter Bright wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> kris wrote:
>>> So, "invariant" is already a keyword ... what about that?
>> I completely missed that one. I think it's a good idea to look into it as a candidate for a qualifier name. Thank you.
> 
> I agree. I think:
> 
> final
> const
> invariant
> 
> for the three cases looks pretty good.

Assuming that 'invariant' = really constant, 'const' = C++ pseudo-const...

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

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

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

Bruno Medeiros wrote:
> 
> For what I got 'invariant' means the data doesn't change at all, like compile time constants, or ROM data. But I didn't understand if it applies to the "immediate-value" only (like 'final'), or transitively to the referenced data too (like 'const'). Clarify?
> 

Its my understanding that 'invariant' becomes part of the type, like 'const'.  So in your terms, it applies to "referenced data".

invariant ANSWER = 42 ;

bool question (invariant int guess) {
  return guess is ANSWER;
}

;)

-- Chris Nicholson-Sauls

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

James Dennett Wrote:
> 
> "final", I think, is a workaround for handling types
> that are accessed through automatically-dereferenced
> GC'd pointers in D.  The auto-deref property hides the
> actual type of those pointers from us, so we can't const-
> qualify them; we just end up adding const to the type to
> which they point.  C++ doesn't work this way, and so
> const does everything that final does and more in C++.
> It's just different.  If you want indirection via a
> reference/pointer, C++ makes you say so, but gives you
> the chance to apply type modifiers to that pointer.  D
> does it invisibly, but then requires extra syntax to be
> able to stop the name being rebindable.
> 

But I think it is'nt key point here. As I understand, const will afect all from the specified stage in the reference chain, unlike C++ const?

Code analogous to this legal C++ code will be compile time error?

struct S { int *x; };

int a = 12;
S s = { &a };
const S *p = &s;
*p->x = 20;  // will be error?

jovo

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!

I think one of us misunderstood.
I parsed that sentence as "I'd have to go through all my D code to keep it working properly", while judging by your reaction you seem to have parsed it as "I'd be happy to go through all my D code and make the necessary changes".
(Note that the connotation(?) is a bit different; neutral/slightly negative vs quite positive)

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

jovo wrote:
> James Dennett Wrote:
>> "final", I think, is a workaround for handling types
>> that are accessed through automatically-dereferenced
>> GC'd pointers in D.  The auto-deref property hides the
>> actual type of those pointers from us, so we can't const-
>> qualify them; we just end up adding const to the type to
>> which they point.  C++ doesn't work this way, and so
>> const does everything that final does and more in C++.
>> It's just different.  If you want indirection via a
>> reference/pointer, C++ makes you say so, but gives you
>> the chance to apply type modifiers to that pointer.  D
>> does it invisibly, but then requires extra syntax to be
>> able to stop the name being rebindable.
>>
> 
> But I think it is'nt key point here. As I understand, const
> will afect all from the specified stage in the reference chain,
> unlike C++ const?
> 
> Code analogous to this legal C++ code will be compile time error?
> 
> struct S { int *x; };
>     int a = 12;
> S s = { &a };
> const S *p = &s;
> *p->x = 20;  // will be error?

Yes. D's const is transitive.

Andrei

Frits van Bommel 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!
> 
> I think one of us misunderstood.
> I parsed that sentence as "I'd have to go through all my D code to keep it working properly", while judging by your reaction you seem to have parsed it as "I'd be happy to go through all my D code and make the necessary changes".
> (Note that the connotation(?) is a bit different; neutral/slightly negative vs quite positive)

Well, I looked up "want" in my dictionary and parsed the sentence accordingly :o).

Andrei

Sean Kelly 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!
> 
> 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)?

No. There will be far more uses for const than for invariant. You can take my word for 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?
> 
> 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'."

That is correct.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Frits van Bommel 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!
>>
>> I think one of us misunderstood.
>> I parsed that sentence as "I'd have to go through all my D code to keep it working properly", while judging by your reaction you seem to have parsed it as "I'd be happy to go through all my D code and make the necessary changes".
>> (Note that the connotation(?) is a bit different; neutral/slightly negative vs quite positive)
> 
> Well, I looked up "want" in my dictionary and parsed the sentence accordingly :o).

Did you look up "would" as well? :P
I read that to mean "if this was changed ..."