Fix implementation of class dtors

[adamdruppe]

If a class dtor was actually virtual, it'd simplify some of druntime and let the attributes (which tbh im not sure are worth the hassle but if they're there we should try to make them usable) actually work.

It'd work like any other virtual overridden method but it would be required to call members.dtor and super.dtor at the end of the function. The compiler could insert this and then apply the attribute rules do it all and tell you what happened.

struct S {
    @system ~this() {}
}
class A {
   @safe ~this() {}
}

class B : A {
    S s; // this needs to be an error under the rules of @safe 
}

So imagine the compiler sees B and tries to do

override ~this() {
       .destroy(s);
       super.~this();
}

The override will automatically inherit the @safe from the base class - good - and the super.~this will work fine (note this will NOT allow you to tighten restrictions like you can with many overrides because the safe child will not be allowed to call the system parent, but will be required to, leading to you requiring trusted instead) but then since it must also destroy all the members, and this member is system, it will fail.

(arguably calling struct ctors from the class dtor is a bit iffy anyway because of gc interaction but that's a whole other discussion, this is just about getting the function to do what it says in the interface)

We don't want the error message to bewilder people and talk about something they didn't know existed but tbh even like "safe destructor cannot call call unsafe ~S.this" is better than nothing.

Then if they write an explicit @trusted ~this() {} then the compiler inserts the members into that instead and allows it - you need an escape hatch somehow.

This is obviously a breaking change in implementation, but I believe it is what the spec actually requires anyway, so arguably any code whose breakage is revealed by this is already non-conforming.

[IgorDeepakM]

Would this lead to that many struct/class members need to implement double dtors (@System and @trusted), then @trusted would just trampoline into the @System dtor?

What do you think about adding unsafe blocks?

override @safe ~this() {
        @unsafe                // or @system
        {
             .destroy(s);       // it's unsafe, but you're boss
        }
       super.~this();
}

Basically when you want to call an unsafe dtor from safe code you must override and manually call it just as you suggested when any member member or inherited method is unsafe.

I was never a big fan of the @trusted designation as it is kind of weird like 11 in a Spinal Tap sketch. No other languages has ever added this extra third state what I know about, only safe and unsafe designations.

[adamdruppe]

You aren't allowed to do double implementations like that, what happens is the trusted one covers both safe and system uses.

But I don't really have an opinion on the unsafe block, a lot of people do that anyway just wordier in regular D lol. so I'm not against it. But here, the compiler would have to recognize that you called the member dtor yourself and not try to inject an automatic call anymore. That's doable, I think it does that elsewhere already for checking constructors.