Practically there is no difference. However I think that there are subtle differences that make my wording of the idea a little bit better. Either way I fully expect that large code bases can switch to the newer standard that has this and the only problems will be existing bugs don't compile. (I know some people reading this have the resources to check that statement, I don't)

Consider

Child::destroyWithoutCleanup() {
...
delete static_cast<base*>(this) ;
}

I would hope nobody writes code like that, (it does look c++98 to me) but it should be legal even if it never is written. This subtle change of wording makes a difference in how it works.

This change of wording also means if there is some real situation we didn't think of there is a work around.

class base {
public:
~base() ; // do not make this virtual because...
} ;

If I thought the above was a real situation I'd go farther and ask for ugly syntaxes like reinterpret_cast<virtual>(=false) which already looks like something that will set off alarm bells in the head of everybody who reads the code.

Last this gives the standard consistency with the general guildline that if you have any virtual functions your destructor is either virtual public or non-virtual protected. Elevating this guideline in the standard would be a nice bit of consistency I think worth going for.


On Tue, Mar 24, 2020, at 13:24, Kilian Henneberger via Std-Proposals wrote:
> Both, making the automatically generated destructor protected (how you
> would word it) and making the delete call ill-formed would lead to the
> same result.
> Personally I do not see any advantage of one over the other.
>
> Am 23.03.2020 um 23:24 schrieb Henry Miller via Std-Proposals:
> > I would word this as if there are any pure virtual functions the automatically generated destructor is protected. It gives the result you want by default, anyone who wants the virtual destructor already has to declare it. And if there really is a reason to have a non virtual public destructor it should be verbose enough to call attention to that unusual situation.
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>