Let's not make invariants const

[Alex Rønne Petersen]

On 03-08-2012 21:36, H. S. Teoh wrote:
> On Fri, Aug 03, 2012 at 09:19:22PM +0200, Alex Rønne Petersen wrote:
> [...]
>> class A
>> {
>>      int i;
>>
>>      invariant()
>>      {
>>          i = 42;
>>      }
>> }
>>
>> Currently doesn't compile:
>>
>> $ dmd test.d
>> test.d(7): Error: can only initialize const member i inside constructor
> [...]
>> I believe this behavior is too strict.
> [...]
>
> IMO, if you need to be changing stuff inside invariants, then you're
> using it wrong. Invariants are intended to verify program logic, not to
> do things like altering object state. The point is to be able to compile
> with invariant code turned off, and still have the program work exactly
> as before.
>
>
> T
>

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.

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

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org