Destroying structs (literally)

[Orvid King via Digitalmars-d]

On 8/29/2014 2:52 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> On Friday, 29 August 2014 at 19:01:51 UTC, Andrei Alexandrescu wrote:
>> On 8/29/14, 3:53 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>>> Jacob Carlborg just recently brought this up in another thread. Isn't it
>>> kind of consensus that calling a destructor from the GC is not a good
>>> idea because of the restrictions that apply in this context? Andrei even
>>> wanted to deprecate destructors for classes because of this. Maybe a
>>> better direction would be to separate the concepts of destruction and
>>> finalization, and introduce two kinds of "destructors" for them.
>>
>> I think we need to stay with what we have. Adding a distinct kind of
>> destructor might be interesting. -- Andrei
>
> Our idea was that an additional destructor (let's call it a finalizer)
> would be helpful because it is backward compatible. The compiler could
> make some validity checks on it, at the least make it nothrow, maybe
> @nogc (but I believe we can relax this restriction), pure (?).
> Disallowing access to references (because they could pointer to already
> destroyed objects) is unfortunately not feasible, because we can't
> distinguish GC pointers from other ones. To avoid the need for code
> duplication, finalizers could always be called implicitly by destructors
> (assuming everything that is allowed in finalizers is also permitted in
> destructors).
>
> Calling destructors from the GC could later be phased out. It is
> technically not a breaking change, because there never was a guarantee
> that they'd be called anyway.

I would say that all of those restrictions, except for nothrow, are 
dependent on the current GC implementation. It is possible to write the 
GC in such a way that you can do GC allocations in a destructor, as well 
as access any GC references you want. The only thing with the GC 
references is that there's no way to guarantee that the referenced 
objects won't have already had their destructor called when the current 
destructor is being called.