Ensuring Predictable Destruction Order in cppfront

[shemeshg]

In cppfront, destructors are not virtual by default, which could lead to an unpredictable destruction order. This behavior differs from the traditional C++ approach, where declaring a virtual destructor in a base class ensures that derived class destructors are called correctly.

cpp2

...
operator=: (
    move this
    ) == {
        // destructor
    }
}

cpp1:

public: constexpr ~MyClass() noexcept;

In cpp2, the custom assignment operator sets a destructor, but without a virtual destructor, the destruction sequence may not be as expected, especially when dealing with inheritance.

should cppfront adopt virtual destructors by default?

[hsutter]

Thanks!

without a virtual destructor, the destruction sequence may not be as expected, especially when dealing with inheritance.

Do you have an example that doesn't work as you expect? The reason I ask is because Cpp2 lowers to Cpp1, and so I think if the derived destructor is not marked virtual the Cpp1 semantics make it so.

For example, this code (edit: corrected to make it actually be a pointer to Base):

main: () = {
    pb: std::unique_ptr<Base> = new<Derived>();
}

Base: type = {
    operator=: (virtual move this) = { std::cout << "Base dtor\n"; }
}
Derived: type = {
    this: Base = ();
    operator=: (move this) = { std::cout << "Derived dtor\n"; }
}

prints

Derived dtor
Base dtor

as expected, right?

should cppfront adopt virtual destructors by default?

I think no, because nonvirtual destructors are important, and if they are virtual by default there'd need to be another novirtual keyword to opt out. Also, the Cpp2 model is that everything is opt-in (including copy and assignment), usually by the convenient of just writing @metafn where metafn is a meta function that supplies defaults; for example, a metafunction like @interface defaults the destructor to being virtual.