On Wed, Mar 25, 2020 at 08:14 Henry Miller via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

That's undefined behaviour unless base has a virtual destructor, in which
case the cast is useless (it still calls Child's destructor)

>
>
> 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
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>