• Stewart Gordon (23/23) Jan 29 2012 Discussion about
• Daniel Murphy (6/13) Jan 29 2012 There is an open pull to allow multiple invariants... but not overloadin...
• Stewart Gordon (6/9) Jan 29 2012
• deadalnix (6/10) Jan 29 2012 Well, this is required if you want the class to be constable at all,
• Walter Bright (2/4) Jan 29 2012 I'd have to agree. invariants should always be const.

Stewart Gordon <smjg_1998 yahoo.com> writes:

Discussion about
http://d.puremagic.com/issues/show_bug.cgi?id=7369
has got me thinking.

On discovering that DMD (2.057) rejects
     invariant() const {}
I had made out that constancy doesn't apply to invariants.  Only later did I
realise it 
does, but requires the syntax
     const invariant() {}

But thinking of it, why should one have to declare invariants as const at all?

Invariants are used to check the integrity of the object, not to modify it, and
so it 
would seem natural that invariants should be automatically const.

The way it is, a type with a non-const invariant cannot have any public const
methods.  I 
can see people sacrificing either invariants or const-correctness to get around
this, 
before they discover the syntax that works for declaring a const invariant.

Notice also that DMD rejects two or more invariants in a single type

     invariant() {}
     const invariant() {}
     immutable invariant() {}

so, unless this is a bug, it isn't in order to have different checks depending
on the 
constancy of either the object or the method called thereon.

What exactly is the intended behaviour here?

And what's your view?  Should we make invariants automatically const?

Stewart.

"Daniel Murphy" <yebblies nospamgmail.com> writes:

 On discovering that DMD (2.057) rejects
     invariant() const {}
 I had made out that constancy doesn't apply to invariants.  Only later did 
 I realise it does, but requires the syntax
     const invariant() {}

Rejecting the first one is just a parser bug.

 Notice also that DMD rejects two or more invariants in a single type

There is an open pull to allow multiple invariants... but not overloading 
them.  It just concatenates them, like unit tests.

 And what's your view?  Should we make invariants automatically const?

Yes, probably.  Once downside is that any private methods you want to call 
will need to be const-correct.  Invariants being const is much less 
restricting than forcing them to be pure/nothrow/safe. 

Stewart Gordon <smjg_1998 yahoo.com> writes:

On 29/01/2012 16:46, Daniel Murphy wrote:
<snip>
 And what's your view?  Should we make invariants automatically const?

 Yes, probably.  Once downside is that any private methods you want to call
 will need to be const-correct.

<snip>

But if you want your class to be const-usable at all, the invariant needs to be
const 
regardless whether we make it automatic or not.

Stewart.

deadalnix <deadalnix gmail.com> writes:

Le 29/01/2012 17:46, Daniel Murphy a écrit :
 And what's your view?  Should we make invariants automatically const?

 Yes, probably.  Once downside is that any private methods you want to call
 will need to be const-correct.  Invariants being const is much less
 restricting than forcing them to be pure/nothrow/safe.

Well, this is required if you want the class to be constable at all, 
whatever the invariant require it or not. So I'd argue that invraiant 
should be automatically const.

This is very important to improve D2 and its lib to be more const 
compliant, and this is a step in the right direction.

Walter Bright <newshound2 digitalmars.com> writes:

On 1/29/2012 10:13 AM, deadalnix wrote:
 This is very important to improve D2 and its lib to be more const compliant,
and
 this is a step in the right direction.

I'd have to agree. invariants should always be const.