Let's not make invariants const

[Davidson Corry]

On 8/3/2012 1:14 PM, Paulo Pinto wrote:
> Personally I feel D's contracts are still a bit off of what Eiffel,
   .NET and Ada 2012 offer.

On 8/3/2012 1:01 PM, Alex Rønne Petersen wrote:
> So what if, for whatever reason, the invariant needs to track and
> maintain some state in order to catch some kind of ugly bug?
>
> I agree that ideally an invariant should not ever need to change state.
> But I think in some cases it can be a useful debugging tool.

The "track and maintain some state" bit usually means capturing some
state at entry to the class (via a public method), so that the invariant
can at exit from the class compare the new, possibly modified, state
to the previous one.

This is the purpose of Eiffel's 'old' construct, which D does not have.
(Yet.) (One hopes.) (And it would be nice to be able to capture an old
*expression* and not just an old variable.)

'old' is used more often with postconditions than with invariants, but
it can be useful in both.

> But even ignoring that, making invariants const at this point in time is
> just not practical. We seem to be doing things in the completely wrong
> order. The library should be made const-friendly and *then* invariants
> could be made const (not that I want them to be anyway).

Certainly the libraries should be made as const-correct as possible. But
it's not like we are forced to do only the one or the other (except for
the insufficient supply of Walters, perhaps...). IMO, invariants should
"be made const" (i.e. statically check for side effects) as discussed
elsewhere. In fact, I believe that having more rigorous contract checks
could *help* improve library code, by making it harder for loose code
to get into the library.