core.exception.InvalidMemoryOperationError@(0)

[Bayan Rafeh via Digitalmars-d-learn]

>
> the thing is that your invariant is not a correct invariant at 
> all.
> invariants are meant to check *internal* object consistency, 
> not external
> conditions. compiler is free to call invariant block at any 
> time after
> object is properly initialised (i.e. after ctor is complete) 
> and is not
> executing member method. so it's perfectly legal to call 
> invariant before
> dtor, as you should not check anything that is not belonging to 
> the
> object itself in in.

> in other words: you can't check any contents of any 
> reference-typed
> variables in your invariant block. `string` is reference-typed 
> (it's a
> dynamic array managed by GC in your case), so you can't check 
> it contents
> in invariant. you CAN, however, use `f` methods in your 
> invariant, as `f`
> is a struct which lives *inside* your object, and not a 
> reference var.
>
> but note that it's a bad practice anyway, as some struct can 
> use some GC-
> managed objects which can't be safely used in invariant block.

There are 2 problems here:

1. By definition, after the destructor is called the object state
is destroyed. It makes no sense to check the invariant after the
destructor is called because there is no state for us to check.

2. Invariants theoretically describe the legal states the object
can be in which includes variables that are GC managed, therefore
I should be able to check the invariant on GC managed objects as
well. What's the point of having this feature if I can't even
check the invariants of a simple data structure like a set, let
alone classes involving files?