Destructor attribute inheritance, yea or nay?

[Stanislav Blinov via Digitalmars-d]

On Friday, 26 May 2017 at 18:58:46 UTC, Igor Shirkalin wrote:

> First, why 'oblivious' function does not free Malicious object 
> (no matter GC or not GC).

It actually does matter. It doesn't manually release the 
resources precisely because it relies on the GC. I've made it 
overly explicit, but in real world it could have just as easily 
been an implicit allocation done by some library function (say, 
Phobos), perhaps even without giving me an actual reference to 
allocated memory. The name of this function reflects this: it 
doesn't know or care what's going on inside it.

> What if 'important' function needs some "external an not safe" 
> resource used by 'oblivious'?

That's the point. 'important' has nothing to do with 'oblivious' 
at all, yet it *may* suffer from side effects that originate in 
'oblivious' at an unspecified point in time during program 
execution. What's worse, at a glance it would look like @safe 
function breaking it's own promise

> 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.

Per language rules, you're not allowed to call @system functions 
in @safe code:

void important() @safe
{
     auto obj = new Malicious();
     obj.destroy(); // this will be a compiler error, destroy() is 
@system
}

However, the runtime currently ignores this altogether, and 
happily calls that same @system function while executing that 
same @safe function, or rather, may or may not call depending on 
conditions beyond our control. If that doesn't sound bad, I don't 
know what does.