Invariant for default construction

[Steven Schveighoffer via Digitalmars-d]

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.

-Steve