------=_Part_1912_1430320223.1536723480067
Content-Type: multipart/alternative;
 boundary="----=_Part_1913_93788375.1536723480067"

------=_Part_1913_93788375.1536723480067
Content-Type: text/plain; charset="UTF-8"

I think that "delete meow;" should be ill-formed if "meow" is of incomplete
type.  Right now, it acts similarly to "operator delete(meow)".  If the
completed type ends up having a destructor, it's undefined behavior.  (As a
practical matter, the behavior in this situation on pretty much every
compiler is simple: the memory is freed, but the destructor is never
called.)

This easily leads to bugs, and it's rather infrequently used.  I don't
think I've ever seen correct code use "delete" on an incomplete type.  It's
also asymmetric with "new": you obviously can't "new" an incomplete type.
The major implementations warn on this (MSVC 4150, GCC/Clang
-Wdelete-incomplete, Intel no idea but it warns too).

Since this is a currently legal construct, it would probably be best to
deprecate first.

Melissa

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6%40isocpp.org.

------=_Part_1913_93788375.1536723480067
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think that &quot;delete meow;&quot; should be ill-f=
ormed if &quot;meow&quot; is of incomplete type.=C2=A0 Right now, it acts s=
imilarly to &quot;operator delete(meow)&quot;.=C2=A0 If the completed type =
ends up having a destructor, it&#39;s undefined behavior.=C2=A0 (As a pract=
ical matter, the behavior in this situation on pretty much every compiler i=
s simple: the memory is freed, but the destructor is never called.)<br></di=
v><div><br></div><div>This easily leads to bugs, and it&#39;s rather infreq=
uently used.=C2=A0 I don&#39;t think I&#39;ve ever seen correct code use &q=
uot;delete&quot; on an incomplete type.=C2=A0 It&#39;s also asymmetric with=
 &quot;new&quot;: you obviously can&#39;t &quot;new&quot; an incomplete typ=
e.=C2=A0 The major implementations warn on this (MSVC 4150, GCC/Clang -Wdel=
ete-incomplete, Intel no idea but it warns too).</div><div><br></div><div>S=
ince this is a currently legal construct, it would probably be best to depr=
ecate first.<br></div><div><br></div><div></div><div>Melissa<br></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6=
%40isocpp.org</a>.<br />

------=_Part_1913_93788375.1536723480067--

------=_Part_1912_1430320223.1536723480067--

.

I agree that something should be done here. An alternative would be to
require that meouws destructor does get called. Im am no linker
expert, but I do believe that it would be possible on all platforms to
create a weak symbol in the object code somehow?
If that is the case this sounds like a better solution to me.

/Peter


On Wed, Sep 12, 2018 at 5:38 AM Myriachan <myriachan@gmail.com> wrote:
>
> I think that "delete meow;" should be ill-formed if "meow" is of incomple=
te type.  Right now, it acts similarly to "operator delete(meow)".  If the =
completed type ends up having a destructor, it's undefined behavior.  (As a=
 practical matter, the behavior in this situation on pretty much every comp=
iler is simple: the memory is freed, but the destructor is never called.)
>
> This easily leads to bugs, and it's rather infrequently used.  I don't th=
ink I've ever seen correct code use "delete" on an incomplete type.  It's a=
lso asymmetric with "new": you obviously can't "new" an incomplete type.  T=
he major implementations warn on this (MSVC 4150, GCC/Clang -Wdelete-incomp=
lete, Intel no idea but it warns too).
>
> Since this is a currently legal construct, it would probably be best to d=
eprecate first.
>
> Melissa
>
> --
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6%40isocpp.=
org.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANPtknwBFPaemWYMHhW%3D9HcFrXkPR5xpUtHQKFM2Hyz1J=
HZgyA%40mail.gmail.com.

.

What if the destructor is protected or private? I often use that trick in m=
y code as a way to enforce lifetime rules. I don't want a language sanction=
ed way to get around my rules.=20

I like the proposal which gets rid of this source of bugs: deprecate and re=
move.=20


On Wed, Sep 12, 2018, at 3:24 AM, Peter Koch Larsen wrote:
> I agree that something should be done here. An alternative would be to
> require that meouws destructor does get called. Im am no linker
> expert, but I do believe that it would be possible on all platforms to
> create a weak symbol in the object code somehow?
> If that is the case this sounds like a better solution to me.
>=20
> /Peter
>=20
>=20
> On Wed, Sep 12, 2018 at 5:38 AM Myriachan <myriachan@gmail.com> wrote:
> >
> > I think that "delete meow;" should be ill-formed if "meow" is of incomp=
lete type.  Right now, it acts similarly to "operator delete(meow)".  If th=
e completed type ends up having a destructor, it's undefined behavior.  (As=
 a practical matter, the behavior in this situation on pretty much every co=
mpiler is simple: the memory is freed, but the destructor is never called.)
> >
> > This easily leads to bugs, and it's rather infrequently used.  I don't =
think I've ever seen correct code use "delete" on an incomplete type.  It's=
 also asymmetric with "new": you obviously can't "new" an incomplete type. =
 The major implementations warn on this (MSVC 4150, GCC/Clang -Wdelete-inco=
mplete, Intel no idea but it warns too).
> >
> > Since this is a currently legal construct, it would probably be best to=
 deprecate first.
> >
> > Melissa
> >
> > --
> > You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send =
an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > To view this discussion on the web visit https://groups.google.com/a/is=
ocpp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6%40isocp=
p.org.
>=20
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknwBFPa=
emWYMHhW%3D9HcFrXkPR5xpUtHQKFM2Hyz1JHZgyA%40mail.gmail.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1536750972.1844032.1505427336.7C79F4BB%40webmail=
..messagingengine.com.

.

The question about the visibility of the destructor should not be a
problem - it can be handled e.g. by giving a public destructor a
special name that will not be resolved if the destructor is private or
protected.

/Peter


On Wed, Sep 12, 2018 at 1:16 PM Henry Miller <hank@millerfarm.com> wrote:
>
>
> What if the destructor is protected or private? I often use that trick in=
 my code as a way to enforce lifetime rules. I don't want a language sancti=
oned way to get around my rules.
>
> I like the proposal which gets rid of this source of bugs: deprecate and =
remove.
>
>
> On Wed, Sep 12, 2018, at 3:24 AM, Peter Koch Larsen wrote:
> > I agree that something should be done here. An alternative would be to
> > require that meouws destructor does get called. Im am no linker
> > expert, but I do believe that it would be possible on all platforms to
> > create a weak symbol in the object code somehow?
> > If that is the case this sounds like a better solution to me.
> >
> > /Peter
> >
> >
> > On Wed, Sep 12, 2018 at 5:38 AM Myriachan <myriachan@gmail.com> wrote:
> > >
> > > I think that "delete meow;" should be ill-formed if "meow" is of inco=
mplete type.  Right now, it acts similarly to "operator delete(meow)".  If =
the completed type ends up having a destructor, it's undefined behavior.  (=
As a practical matter, the behavior in this situation on pretty much every =
compiler is simple: the memory is freed, but the destructor is never called=
..)
> > >
> > > This easily leads to bugs, and it's rather infrequently used.  I don'=
t think I've ever seen correct code use "delete" on an incomplete type.  It=
's also asymmetric with "new": you obviously can't "new" an incomplete type=
..  The major implementations warn on this (MSVC 4150, GCC/Clang -Wdelete-in=
complete, Intel no idea but it warns too).
> > >
> > > Since this is a currently legal construct, it would probably be best =
to deprecate first.
> > >
> > > Melissa
> > >
> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "ISO C++ Standard - Future Proposals" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to std-proposals+unsubscribe@isocpp.org.
> > > To post to this group, send email to std-proposals@isocpp.org.
> > > To view this discussion on the web visit https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/3878ce67-de63-4fb6-98bf-24a45d1a07d6%40iso=
cpp.org.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > To view this discussion on the web visit
> > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknwBF=
PaemWYMHhW%3D9HcFrXkPR5xpUtHQKFM2Hyz1JHZgyA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/1536750972.1844032.1505427336.7C79F4BB%40webma=
il.messagingengine.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANPtknxk90E%3Dhrna62pgYm%3Dx7BAi7z42d9_20k8CLM3=
qk_%2BsfQ%40mail.gmail.com.

.

On Wednesday, 12 September 2018 01:24:13 PDT Peter Koch Larsen wrote:
> I agree that something should be done here. An alternative would be to
> require that meouws destructor does get called. Im am no linker
> expert, but I do believe that it would be possible on all platforms to
> create a weak symbol in the object code somehow?

The problem is that some destructor symbols already are weak, if they are
defined as inline in a header. Then the linker wouldn't know which of the weak
ones to select: they'd have the same weight.

There's also the question of which of the multiple destructor functions to
call. The IA-64 C++ ABI has 3 different destructor symbols and two of them are
relevant for this case: the complete destructor and the deleting destructor.
The deleting destructor is not emitted for non-polymorphic classes. The other
ABIs will have different semantics, but they all have multiple symbols.

Finally, and most importantly, if the destructor is virtual, then it should be
called via the vtable. To do that, the compiler needs to know the offset of
the vtable in the object and the destructor's slot in the vtable, which means
the class cannot incomplete.

> If that is the case this sounds like a better solution to me.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1809777.UTzFbt1D0Y%40tjmaciei-mobl1.

.

On Wednesday, 12 September 2018 06:51:22 PDT Peter Koch Larsen wrote:
> The question about the visibility of the destructor should not be a
> problem - it can be handled e.g. by giving a public destructor a
> special name that will not be resolved if the destructor is private or
> protected.

Major ABI break.

Not to mention that in your solution, the weak symbol the compiler emitted
would not be overridden, so the deletion would still continue as it is today.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1630149.0IFaoDlPHQ%40tjmaciei-mobl1.

.

On Tuesday, 11 September 2018 20:38:00 PDT Myriachan wrote:
>  think that "delete meow;" should be ill-formed if "meow" is of incomplete
> type.  Right now, it acts similarly to "operator delete(meow)".  If the
> completed type ends up having a destructor, it's undefined behavior.  (As a
> practical matter, the behavior in this situation on pretty much every
> compiler is simple: the memory is freed, but the destructor is never
> called.)
>
> This easily leads to bugs, and it's rather infrequently used.  I don't
> think I've ever seen correct code use "delete" on an incomplete type.  It's
> also asymmetric with "new": you obviously can't "new" an incomplete type.
> The major implementations warn on this (MSVC 4150, GCC/Clang
> -Wdelete-incomplete, Intel no idea but it warns too).
>
> Since this is a currently legal construct, it would probably be best to
> deprecate first.

I agree, I don't understand why this is allowed. It's almost always a recipe
for errors.

There is one type that should be excepted: void. It is incomplete and deleting
void* should of course still be permitted. This is also the escape hatch for
code that really needs to free memory for incomplete types: just cast to
void*:

 delete reinterpret_cast<void *>(ptr);

Which is equivalent to:

 ::operator delete(reinterpret_cast<void*>(ptr));

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5231037.cu0SFou1db%40tjmaciei-mobl1.

.

On 12 September 2018 at 18:25, Thiago Macieira <thiago@macieira.org> wrote:
>> Since this is a currently legal construct, it would probably be best to
>> deprecate first.
>
> I agree, I don't understand why this is allowed. It's almost always a recipe
> for errors.

It's UB.  Beats me why it's not plain ill-formed, I agree with Myria
that it should be.

> There is one type that should be excepted: void. It is incomplete and deleting
> void* should of course still be permitted. This is also the escape hatch for

"Still be permitted"? Deleting a void* is ill-formed, as it should be.

> code that really needs to free memory for incomplete types: just cast to
> void*:
>
>         delete reinterpret_cast<void *>(ptr);
>
> Which is equivalent to:
>
>         ::operator delete(reinterpret_cast<void*>(ptr));

If you wish to free memory, call operator delete like you're supposed
to do, i.e. your
second snippet is your escape hatch. The explicit cast to void* is unnecessary.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaUz6YMh9cXs0CEcGgc1TK_ZULKE7QwLGZujNXS89mZ8g%40mail.gmail.com.

.

------=_Part_160_1101720739.1536789649917
Content-Type: multipart/alternative;
 boundary="----=_Part_161_1485806792.1536789649917"

------=_Part_161_1485806792.1536789649917
Content-Type: text/plain; charset="UTF-8"

On Wednesday, September 12, 2018 at 9:06:32 AM UTC-7, Ville Voutilainen
wrote:
>
> On 12 September 2018 at 18:25, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
> >> Since this is a currently legal construct, it would probably be best to
> >> deprecate first.
> >
> > I agree, I don't understand why this is allowed. It's almost always a
> recipe
> > for errors.
>
> It's UB.  Beats me why it's not plain ill-formed, I agree with Myria
> that it should be.
>
>
If I wanted to file this, would it best be a proposal or a defect report?
Also, would it really be better to deprecate instead of remove it?

Thanks!

Melissa

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d11f7a5d-ea98-4cc9-a869-7be89ba01d9c%40isocpp.org.

------=_Part_161_1485806792.1536789649917
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, September 12, 2018 at 9:06:32 AM UTC-7, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 Sept=
ember 2018 at 18:25, Thiago Macieira &lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"agI7X7sTBwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">thi...@macieira.org</a>&gt; wrote:
<br>&gt;&gt; Since this is a currently legal construct, it would probably b=
e best to
<br>&gt;&gt; deprecate first.
<br>&gt;
<br>&gt; I agree, I don&#39;t understand why this is allowed. It&#39;s almo=
st always a recipe
<br>&gt; for errors.
<br>
<br>It&#39;s UB. =C2=A0Beats me why it&#39;s not plain ill-formed, I agree =
with Myria
<br>that it should be.
<br>
<br></blockquote><div><br></div><div>If I wanted to file this, would it bes=
t be a proposal or a defect report?=C2=A0 Also, would it really be better t=
o deprecate instead of remove it?</div><div><br></div><div>Thanks!</div><di=
v><br></div><div>Melissa<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d11f7a5d-ea98-4cc9-a869-7be89ba01d9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d11f7a5d-ea98-4cc9-a869-7be89ba01d9c=
%40isocpp.org</a>.<br />

------=_Part_161_1485806792.1536789649917--

------=_Part_160_1101720739.1536789649917--

.

On 13 September 2018 at 01:00, Myriachan <myriachan@gmail.com> wrote:
> On Wednesday, September 12, 2018 at 9:06:32 AM UTC-7, Ville Voutilainen
> wrote:
>>
>> On 12 September 2018 at 18:25, Thiago Macieira <thi...@macieira.org>
>> wrote:
>> >> Since this is a currently legal construct, it would probably be best to
>> >> deprecate first.
>> >
>> > I agree, I don't understand why this is allowed. It's almost always a
>> > recipe
>> > for errors.
>>
>> It's UB.  Beats me why it's not plain ill-formed, I agree with Myria
>> that it should be.
>>
>
> If I wanted to file this, would it best be a proposal or a defect report?
> Also, would it really be better to deprecate instead of remove it?

A proposal targeting Evolution; it's a design change, not a defect. I
would think it's perfectly
reasonable to propose making the current UB ill-formed, the committee
will say if they want
deprecation instead, and it's not difficult to make such a change on
the fly during a meeting.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb0qtsyUwrA4mZLQznk319-gP7G6%3DvSjUXfZ0pyLKwz%3Dw%40mail.gmail.com.

.

Yes - to solve this, the call would have to not be to the  destructor
but rather a stand-alone function that would have to be generated to
every class generated. Something like __external_delete(meouw* m) {
delete m; }.

Not sure if it is worth the trouble. Or rather: rather sure it would
not be worth the trouble

/Peter


On Wed, Sep 12, 2018 at 5:23 PM Thiago Macieira <thiago@macieira.org> wrote:
>
> On Wednesday, 12 September 2018 06:51:22 PDT Peter Koch Larsen wrote:
> > The question about the visibility of the destructor should not be a
> > problem - it can be handled e.g. by giving a public destructor a
> > special name that will not be resolved if the destructor is private or
> > protected.
>
> Major ABI break.
>
> Not to mention that in your solution, the weak symbol the compiler emitted
> would not be overridden, so the deletion would still continue as it is today.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1630149.0IFaoDlPHQ%40tjmaciei-mobl1.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknwetz9oyQqjfK5E2nVVs%3DnCfCBRd%3DDmFTTb3G0oi8zT3g%40mail.gmail.com.

.

On Thursday, 13 September 2018 00:57:52 PDT Peter Koch Larsen wrote:
> Yes - to solve this, the call would have to not be to the  destructor
> but rather a stand-alone function that would have to be generated to
> every class generated. Something like __external_delete(meouw* m) {
> delete m; }.

In the IA-64 C++ ABI, this function type exists and is called a deleting
destructor. But it's only emitted for types with virtual destructors. Here's
an example of a class for which the compiler will not emit the deleting
destructor:

struct S {};

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3226382.DoP1sjDmp2%40tjmaciei-mobl1.

.