Destructor attribute inheritance, yea or nay?

[Igor Shirkalin via Digitalmars-d]

On Friday, 26 May 2017 at 17:48:24 UTC, Stanislav Blinov wrote:
>> I'm sorry, I ment explicitly. I hope it is not possible.
>
> It is very possible, and it should be possible, otherwise we 
> couldn't even think about deterministic destruction.
Hm, you've said it is decision of GC (see bellow), so how can it 
be deterministic?
>
>>> Another side, clearly demonstrated by my second post, is that 
>>> non-deterministic destruction cannot be @safe, period. 
>>> Because when GC collects and calls destructors, it calls all 
>>> of them, regardless of their @safe status, even when the 
>>> collection is triggered inside a @safe function.
>>
>> Doesn't that mean if compiler can't call inherited destructor 
>> despite of GC it must be error?
>
> 1) Destructors are not "inherited" in D. Each derived class has 
> it's own independent destructor. That's why they don't inherit 
> any attributes either.
>
> 2) Compiler doesn't call destructors for classes. It is done 
> either manually (by calling destroy()) or by the GC. Look at 
> the example in the second post: I'm in @safe function 
> (important()), I need some memory. I ask for it, the GC decides 
> to do a collection before giving me memory. And during that 
> collection it calls a @system destructor.
> So the language and runtime are effectively in disagreement: 
> language says "no @system calls in @safe context", runtime says 
> "whatever, I need to call those destructors".

Your example is very interesting and it derives some questions.
First, why 'oblivious' function does not free Malicious object 
(no matter GC or not GC). What if 'important' function needs some 
"external an not safe" resource used by 'oblivious'? Is it all 
about @safe that stops allowing it? If so, @safe is really 
important feature in Dlang. Second, same as first, it looks like 
I got it.