https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #11 from Walter Bright <bugzilla@digitalmars.com> ---
I agree that the invariant should run on non-empty struct literals and on destruction.

I'm skeptical, however, of the value of running it on default construction, as those values will always be the .init ones.

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #12 from Walter Bright <bugzilla@digitalmars.com> ---
https://github.com/D-Programming-Language/dmd/pull/4136

(But does not do invariant call for default construction, will change spec to
say that isn't don't.)

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #13 from Walter Bright <bugzilla@digitalmars.com> ---
Documentation fix:

https://github.com/D-Programming-Language/dlang.org/pull/699

--

https://issues.dlang.org/show_bug.cgi?id=519

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #14 from Martin Nowak <code@dawg.eu> ---
Rainer raised an important question for running invariant before class destruction. Because GC finalization order is undetermined an invariant that would check whether some classes's field points to a valid instance could fail because the pointed-to class could already have been finalized.


http://forum.dlang.org/post/m4eu6v$trq$1@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=519

Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|andrej.mitrovich@gmail.com  |

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #15 from Stewart Gordon <smjg@iname.com> ---
(In reply to Walter Bright from comment #11)
> I'm skeptical, however, of the value of running it on default construction, as those values will always be the .init ones.

Maybe have a rule that, if the -unittest option is set, autogenerate a unittest to call the invariant on the .init.

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #16 from Andrei Alexandrescu <andrei@erdani.com> ---
I stated this elsewhere, just making sure I don't forget: probably we don't want to invoke invariants during the GC cycle.

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #17 from Martin Nowak <code@dawg.eu> ---
(In reply to Andrei Alexandrescu from comment #16)
> I stated this elsewhere, just making sure I don't forget: probably we don't want to invoke invariants during the GC cycle.

Walter has a different opinion on this, I don't follow his argument though. http://forum.dlang.org/post/m753hk$pt2$1@digitalmars.com

Currently it can't be done, because the calls to the invariant are embedded into the generated destructor function.

Also the invariant is called twice, before and after running the destructor. The latter forces one to perform additional cleanup, e.g. setting pointers to null.

--

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #18 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Martin Nowak from comment #17)
> (In reply to Andrei Alexandrescu from comment #16)
> > I stated this elsewhere, just making sure I don't forget: probably we don't want to invoke invariants during the GC cycle.
> 
> Walter has a different opinion on this, I don't follow his argument though. http://forum.dlang.org/post/m753hk$pt2$1@digitalmars.com
> 
> Currently it can't be done, because the calls to the invariant are embedded into the generated destructor function.

Well a simple invariant would be:

assert(this.parent.child is this);

which would be placed in some child node, or could be moved in parent like this:

assert(this.child.parent is this);

The invariant involves two objects no matter where you put it.

> Also the invariant is called twice, before and after running the destructor. The latter forces one to perform additional cleanup, e.g. setting pointers to null.

That's definitely a problem. Invariants are not supposed to hold after destruction.

--

https://issues.dlang.org/show_bug.cgi?id=519

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D2

--