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
[email protected]
http://lycus.org
