Invariant for default construction

[Rainer Schuetze via Digitalmars-d]

On 19.11.2014 21:08, Steven Schveighoffer wrote:
> On 11/19/14 3:46 AM, Daniel Murphy wrote:
>> "Rainer Schuetze"  wrote in message news:m4eu6v$trq$1 at digitalmars.com...
>>
>>> I remember having an invariant on a tree structure checking
>>> consistency by verifying the children and parent references. This
>>> crashed when adding a destructor. With the proposed change it will
>>> always crash.
>>>
>>> The problem is that the destructors of the tree nodes are called in
>>> arbitrary order when they are collected by the GC. Class instances are
>>> also made invalid after calling the destructor (the vtbl is zeroed).
>>>
>>> I wonder if
>>>
>>> - such invariants are invalid,
>>> - the GC should bypass the invariant when calling the destructor
>>> - or we should never call the invariant with the destructor?
>>
>> I think the 'correct' solution is to check the invariants before any of
>> the parts are destroyed.
>
> This may sound feasible, but it rules out some GC algorithms, as the GC
> may free things and destroy them in pieces, and not worry about the
> reachability. I don't think we should provide any guarantees about
> destructors being able to access GC data.
>
> We really *REALLY* need a mechanism to determine whether destruction is
> happening in a GC or not. In synchronous destruction (i.e. destroy or
> scoped), you can run the invariant. In GC, you cannot.

That would be quite within reach for classes with the current GC if the 
compiler would not generate the invariant into the destructor at all, 
but leave it up to to _d_delclass to call it. The GC uses rt_finalize2 
to destroy collected objects and skip the invariant.

A similar mechanism is possible for structs, but
- the invariant needs to be added to the type info
- the compiler needs to generate code to call both the invariant and the 
destructor, or delegate this to a callback in the runtime