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.
