--001a1143d0e0b2b9b305330c0b03
Content-Type: text/plain; charset=UTF-8

Is there any modern reason not to allow an in-class definition of an
abstract method?

e.g.

class C
{
    virtual size_t size() = 0;
    {
        return sizeof(*this);
    }
};

--
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/CAFdMc-3aDnR7sHtOWN%3D%2BQ1d9Hfip%2B61rC5E-2NWdYo-qGifiCA%40mail.gmail.com.

--001a1143d0e0b2b9b305330c0b03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is there any modern reason not to allow an in-class defini=
tion of an abstract method?<br><br>e.g.<br><br>class C<br>{<br>=C2=A0=C2=A0=
=C2=A0 virtual size_t size() =3D 0;<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return sizeof(*this);<br>=C2=A0=C2=A0=C2=A0 =
}<br>};<br><br clear=3D"all"><div><div><br></div></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/CAFdMc-3aDnR7sHtOWN%3D%2BQ1d9Hfip%2B6=
1rC5E-2NWdYo-qGifiCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3aDn=
R7sHtOWN%3D%2BQ1d9Hfip%2B61rC5E-2NWdYo-qGifiCA%40mail.gmail.com</a>.<br />

--001a1143d0e0b2b9b305330c0b03--

.

------=_Part_4778_2053319128.1463530769256
Content-Type: multipart/alternative;
 boundary="----=_Part_4779_782849771.1463530769256"

------=_Part_4779_782849771.1463530769256
Content-Type: text/plain; charset=UTF-8

On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
>
> Is there any modern reason not to allow an in-class definition of an
> abstract method?
>

Well, considering that despite all this
<http://stackoverflow.com/questions/5481941/c-pure-virtual-function-have-body>,
I still haven't seen a good reason to allow a definition for an
pure-virtual method *period*, I see no reason to allow the seeming
contradiction of a pure-virtual method with a definition written inline.

--
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/1380ff95-7204-4092-afe9-a43812d355cf%40isocpp.org.

------=_Part_4779_782849771.1463530769256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Is there a=
ny modern reason not to allow an in-class definition of an abstract method?=
<br></div></blockquote><div><br>Well, considering that <a href=3D"http://st=
ackoverflow.com/questions/5481941/c-pure-virtual-function-have-body">despit=
e all this</a>, I still haven&#39;t seen a good reason to allow a definitio=
n for an pure-virtual method <i>period</i>, I see no reason to allow the se=
eming contradiction of a pure-virtual method with a definition written inli=
ne.</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/1380ff95-7204-4092-afe9-a43812d355cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1380ff95-7204-4092-afe9-a43812d355cf=
%40isocpp.org</a>.<br />

------=_Part_4779_782849771.1463530769256--

------=_Part_4778_2053319128.1463530769256--

.

------=_Part_1315_1689195966.1463551256307
Content-Type: multipart/alternative;
 boundary="----=_Part_1316_980603806.1463551256307"

------=_Part_1316_980603806.1463551256307
Content-Type: text/plain; charset=UTF-8

Actually I like being able to do this and would welcome its addition.  I
know some people don't but since I see nothing dangerous about it I do not
see why we should not do this.  Something only needs to be occasionally
useful to a small group of people to be worth putting in the standard.

On Tuesday, 17 May 2016 17:15:14 UTC+1, dgutson wrote:
>
> Is there any modern reason not to allow an in-class definition of an
> abstract method?
>
> e.g.
>
> class C
> {
>     virtual size_t size() = 0;
>     {
>         return sizeof(*this);
>     }
> };
>
>
>

--
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/1d38158d-9244-460e-928c-2661f2452fc5%40isocpp.org.

------=_Part_1316_980603806.1463551256307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Actually I like being able to do this and would welcome it=
s addition. =C2=A0I know some people don&#39;t but since I see nothing dang=
erous about it I do not see why we should not do this. =C2=A0Something only=
 needs to be occasionally useful to a small group of people to be worth put=
ting in the standard.<br><br>On Tuesday, 17 May 2016 17:15:14 UTC+1, dgutso=
n  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Is t=
here any modern reason not to allow an in-class definition of an abstract m=
ethod?<br><br>e.g.<br><br>class C<br>{<br>=C2=A0=C2=A0=C2=A0 virtual size_t=
 size() =3D 0;<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 return sizeof(*this);<br>=C2=A0=C2=A0=C2=A0 }<br>};<br><br clear=
=3D"all"><div><div><br></div></div></div>
</blockquote></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/1d38158d-9244-460e-928c-2661f2452fc5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d38158d-9244-460e-928c-2661f2452fc5=
%40isocpp.org</a>.<br />

------=_Part_1316_980603806.1463551256307--

------=_Part_1315_1689195966.1463551256307--

.

On Tue, May 17, 2016 at 9:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
>>
>> Is there any modern reason not to allow an in-class definition of an
>> abstract method?
>
>
> Well, considering that despite all this, I still haven't seen a good reas=
on
> to allow a definition for an pure-virtual method period, I see no reason =
to
> allow the seeming contradiction of a pure-virtual method with a definitio=
n
> written inline.

I'm not asking whether allowing a definition for a pure-virtual method
is OK or not, that's out of discussion, it's already in the std period
:)
I'm asking about whether there is a preventing reason to not to allow
in-class definition or not.

>
> --
> 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/1380ff95-720=
4-4092-afe9-a43812d355cf%40isocpp.org.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3z4OZToiUV1d_JfZCKz_RNOxzkWmUaSt9Rp76%2B%=
2B7426g%40mail.gmail.com.

.

------=_Part_272_948953343.1463581497591
Content-Type: multipart/alternative;
 boundary="----=_Part_273_754918839.1463581497591"

------=_Part_273_754918839.1463581497591
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 18, 2016 at 9:46:38 AM UTC-4, dgutson wrote:
>
> On Tue, May 17, 2016 at 9:19 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
> >>
> >> Is there any modern reason not to allow an in-class definition of an
> >> abstract method?
> >
> >
> > Well, considering that despite all this, I still haven't seen a good
> reason
> > to allow a definition for an pure-virtual method period, I see no reason
> to
> > allow the seeming contradiction of a pure-virtual method with a
> definition
> > written inline.
>
> I'm not asking whether allowing a definition for a pure-virtual method
> is OK or not, that's out of discussion, it's already in the std period
> :)

I'm asking about whether there is a preventing reason to not to allow
> in-class definition or not.
>

From a technical standpoint, there is no reason why it *can't* be done.
That is, the language grammar could be modified to handle it without
breaking anything. And it would be functional within the language, since
you can declare such members inline already.

But from a "good for the language" standpoint, the fact that defining
pure-virtual methods is not a good feature is *precisely why* we shouldn't
allow inline definitions. We don't want to legitimize a misfeature by
making it more usable.

Better for it to look like an old spec bug than to suggest that it's ever a
good idea.

--
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/d044ed9f-72a3-4a9b-b9e7-5daf8c1e1369%40isocpp.org.

------=_Part_273_754918839.1463581497591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, May 18, 2016 at 9:46:38 AM UTC-4, dgutson wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, May 17, 2016 at 9:=
19 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"atvpeo9rCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
<br>&gt;&gt;
<br>&gt;&gt; Is there any modern reason not to allow an in-class definition=
 of an
<br>&gt;&gt; abstract method?
<br>&gt;
<br>&gt;
<br>&gt; Well, considering that despite all this, I still haven&#39;t seen =
a good reason
<br>&gt; to allow a definition for an pure-virtual method period, I see no =
reason to
<br>&gt; allow the seeming contradiction of a pure-virtual method with a de=
finition
<br>&gt; written inline.
<br>
<br>I&#39;m not asking whether allowing a definition for a pure-virtual met=
hod
<br>is OK or not, that&#39;s out of discussion, it&#39;s already in the std=
 period
<br>:)
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I&#39;m ask=
ing about whether there is a preventing reason to not to allow
<br>in-class definition or not.
<br></blockquote><div><br>From a technical standpoint, there is no reason w=
hy it <i>can&#39;t</i> be done. That is, the language grammar could be modi=
fied to handle it without breaking anything. And it would be functional wit=
hin the language, since you can declare such members inline already.<br><br=
>But from a &quot;good for the language&quot; standpoint, the fact that def=
ining pure-virtual methods is not a good feature is <i>precisely why</i> we=
 shouldn&#39;t allow inline definitions. We don&#39;t want to legitimize a =
misfeature by making it more usable. <br><br>Better for it to look like an =
old spec bug than to suggest that it&#39;s ever a good idea.<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/d044ed9f-72a3-4a9b-b9e7-5daf8c1e1369%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d044ed9f-72a3-4a9b-b9e7-5daf8c1e1369=
%40isocpp.org</a>.<br />

------=_Part_273_754918839.1463581497591--

------=_Part_272_948953343.1463581497591--

.

On Wed, May 18, 2016 at 11:24 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, May 18, 2016 at 9:46:38 AM UTC-4, dgutson wrote:
>>
>> On Tue, May 17, 2016 at 9:19 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
>> >>
>> >> Is there any modern reason not to allow an in-class definition of an
>> >> abstract method?
>> >
>> >
>> > Well, considering that despite all this, I still haven't seen a good
>> > reason
>> > to allow a definition for an pure-virtual method period, I see no reas=
on
>> > to
>> > allow the seeming contradiction of a pure-virtual method with a
>> > definition
>> > written inline.
>>
>> I'm not asking whether allowing a definition for a pure-virtual method
>> is OK or not, that's out of discussion, it's already in the std period
>> :)
>>
>> I'm asking about whether there is a preventing reason to not to allow
>> in-class definition or not.
>
>
> From a technical standpoint, there is no reason why it can't be done. Tha=
t
> is, the language grammar could be modified to handle it without breaking
> anything. And it would be functional within the language, since you can
> declare such members inline already.
>
> But from a "good for the language" standpoint, the fact that defining
> pure-virtual methods is not a good feature is precisely why we shouldn't
> allow inline definitions. We don't want to legitimize a misfeature by mak=
ing
> it more usable.

I agree with that last statement in general, but why *you
individually* consider this a misfeature? What's exactly wrong with
this from your personal POV?

>
> Better for it to look like an old spec bug than to suggest that it's ever=
 a
> good idea.
>
> --
> 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/d044ed9f-72a=
3-4a9b-b9e7-5daf8c1e1369%40isocpp.org.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-12qKPv7uP%3D504gNStnZmh_4xXN_DgSg%2B9nZVR=
5OQKC2w%40mail.gmail.com.

.

------=_Part_143_2094277302.1463583943427
Content-Type: multipart/alternative;
 boundary="----=_Part_144_523844986.1463583943427"

------=_Part_144_523844986.1463583943427
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 18, 2016 at 10:29:45 AM UTC-4, dgutson wrote:
>
> On Wed, May 18, 2016 at 11:24 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Wednesday, May 18, 2016 at 9:46:38 AM UTC-4, dgutson wrote:
> >>
> >> On Tue, May 17, 2016 at 9:19 PM, Nicol Bolas <jmck...@gmail.com>
> wrote:
> >> > On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wrote:
> >> >>
> >> >> Is there any modern reason not to allow an in-class definition of an
> >> >> abstract method?
> >> >
> >> >
> >> > Well, considering that despite all this, I still haven't seen a good
> >> > reason
> >> > to allow a definition for an pure-virtual method period, I see no
> reason
> >> > to
> >> > allow the seeming contradiction of a pure-virtual method with a
> >> > definition
> >> > written inline.
> >>
> >> I'm not asking whether allowing a definition for a pure-virtual method
> >> is OK or not, that's out of discussion, it's already in the std period
> >> :)
> >>
> >> I'm asking about whether there is a preventing reason to not to allow
> >> in-class definition or not.
> >
> >
> > From a technical standpoint, there is no reason why it can't be done.
> That
> > is, the language grammar could be modified to handle it without breaking
> > anything. And it would be functional within the language, since you can
> > declare such members inline already.
> >
> > But from a "good for the language" standpoint, the fact that defining
> > pure-virtual methods is not a good feature is precisely why we shouldn't
> > allow inline definitions. We don't want to legitimize a misfeature by
> making
> > it more usable.
>
> I agree with that last statement in general, but why *you
> individually* consider this a misfeature? What's exactly wrong with
> this from your personal POV?
>

My feelings on the whole idea comes down to this: what does it *mean* for a
base class to define a function that is pure-virtual? What is the code
trying to say about that function? Here's what I mean.

A function is supposed to perform a task, and a function's name should
ideally explain what that task is. Under this idea, a pure virtual function
means that the base class is functionally incapable of performing the task
X, so it is deferring that to its derived classes. Concrete derived classes
must be able to perform X.

So what is the meaning behind saying that derived classes must perform task
X, but base classes *also* can perform task X?

Is the base class saying that there is some portion of task X which the
base class must perform, and thus derived class overrides of X must tell it
to do? If so, then the pure-virtual&definition isn't the best way to do
that. The best way to do that is to have X be a base class *non-virtual*
member function, which calls a private pure-virtual member function that
derived classes must override. This mechanism *ensures* that the base class
X gets called, rather than *hoping* that the derived classes will do the
right thing.

Relying on hope is a short path to broken code. If something needs to
happen, your code should be structed such that it *must*.

The closest thing to a situation where someone might want this is if there
is some common code that different derived classes might use (or might not)
in the performance of task X. So you move that into the base class, where
they can all access it. I agree with doing that, but...

Why do you need to call that function X at all? Since the base class
function is only *partially* performing task X, it should not use the same
name as the functions which do X in its entirety. It should have a name
that is more befitting of what it does.

This also means that users don't have to use the painful
`base_class::func_name` syntax to call it. It also permits the function to
have a different interface and return values from the actual X, which may
also be more befitting of what it's actually doing. The pure-virtual X may
not be a `const` member function, but the base class subset very well could
be a `const` function. And so forth.

There is a use case that almost seems legitimate: pure-virtual destructors.
It is effectively identical to the case of a base class and derived class
both needing to do their part of some work. The difference is that the
compiler will *ensure* that all destructors are called.

But even that is iffy. Why? Because if the destructor is declared virtual
in a base class... why do you need the destructor to be *pure* virtual? You
have no reason to *force* derived classes to implement a destructor. By the
rules of C++, having a virtual destructor *at all* will guarantee that all
destructors are called, in the proper order, when any instance of the class
is destroyed through a pointer/reference to any type in the hierarchy. If a
particular derived class has no additional cleanup work to do... that's *their
business*. There's no need to make them write an empty destructor or to
explicitly `= default` one.

I simply don't see a use case where there isn't a better alternative.

--
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/5d514e26-9931-4b4f-90c9-06f3becb1386%40isocpp.org.

------=_Part_144_523844986.1463583943427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, May 18, 2016 at 10:29:45 AM UTC-4, d=
gutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, May 18, 2=
016 at 11:24 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"0djq6eltCgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Wednesday, May 18, 2016 at 9:46:38 AM UTC-4, dgutson wrote:
<br>&gt;&gt;
<br>&gt;&gt; On Tue, May 17, 2016 at 9:19 PM, Nicol Bolas &lt;<a>jmck...@gm=
ail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; On Tuesday, May 17, 2016 at 12:15:14 PM UTC-4, dgutson wr=
ote:
<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; Is there any modern reason not to allow an in-class d=
efinition of an
<br>&gt;&gt; &gt;&gt; abstract method?
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Well, considering that despite all this, I still haven&#3=
9;t seen a good
<br>&gt;&gt; &gt; reason
<br>&gt;&gt; &gt; to allow a definition for an pure-virtual method period, =
I see no reason
<br>&gt;&gt; &gt; to
<br>&gt;&gt; &gt; allow the seeming contradiction of a pure-virtual method =
with a
<br>&gt;&gt; &gt; definition
<br>&gt;&gt; &gt; written inline.
<br>&gt;&gt;
<br>&gt;&gt; I&#39;m not asking whether allowing a definition for a pure-vi=
rtual method
<br>&gt;&gt; is OK or not, that&#39;s out of discussion, it&#39;s already i=
n the std period
<br>&gt;&gt; :)
<br>&gt;&gt;
<br>&gt;&gt; I&#39;m asking about whether there is a preventing reason to n=
ot to allow
<br>&gt;&gt; in-class definition or not.
<br>&gt;
<br>&gt;
<br>&gt; From a technical standpoint, there is no reason why it can&#39;t b=
e done. That
<br>&gt; is, the language grammar could be modified to handle it without br=
eaking
<br>&gt; anything. And it would be functional within the language, since yo=
u can
<br>&gt; declare such members inline already.
<br>&gt;
<br>&gt; But from a &quot;good for the language&quot; standpoint, the fact =
that defining
<br>&gt; pure-virtual methods is not a good feature is precisely why we sho=
uldn&#39;t
<br>&gt; allow inline definitions. We don&#39;t want to legitimize a misfea=
ture by making
<br>&gt; it more usable.
<br>
<br>I agree with that last statement in general, but why *you
<br>individually* consider this a misfeature? What&#39;s exactly wrong with
<br>this from your personal POV?
<br></blockquote><div><br>My feelings on the whole idea comes down to this:=
 what does it <i>mean</i> for a base class to define a function that is pur=
e-virtual? What is the code trying to say about that function? Here&#39;s w=
hat I mean.<br><br>A function is supposed to perform a task, and a function=
&#39;s name should ideally explain what that task is. Under this idea, a pu=
re virtual function means that the base class is functionally incapable of =
performing the task X, so it is deferring that to its derived classes. Conc=
rete derived classes must be able to perform X.<br><br>So what is the meani=
ng behind saying that derived classes must perform task X, but base classes=
 <i>also</i> can perform task X?<br><br>Is the base class saying that there=
 is some portion of task X which the base class must perform, and thus deri=
ved class overrides of X must tell it to do? If so, then the pure-virtual&a=
mp;definition isn&#39;t the best way to do that. The best way to do that is=
 to have X be a base class <i>non-virtual</i> member function, which calls =
a private pure-virtual member function that derived classes must override. =
This mechanism <i>ensures</i> that the base class X gets called, rather tha=
n <i>hoping</i> that the derived classes will do the right thing.<br><br>Re=
lying on hope is a short path to broken code. If something needs to happen,=
 your code should be structed such that it <i>must</i>.<br><br>The closest =
thing to a situation where someone might want this is if there is some comm=
on code that different derived classes might use (or might not) in the perf=
ormance of task X. So you move that into the base class, where they can all=
 access it. I agree with doing that, but...<br><br>Why do you need to call =
that function X at all? Since the base class function is only <i>partially<=
/i> performing task X, it should not use the same name as the functions whi=
ch do X in its entirety. It should have a name that is more befitting of wh=
at it does.<br><br>This also means that users don&#39;t have to use the pai=
nful `base_class::func_name` syntax to call it. It also permits the functio=
n to have a different interface and return values from the actual X, which =
may also be more befitting of what it&#39;s actually doing. The pure-virtua=
l X may not be a `const` member function, but the base class subset very we=
ll could be a `const` function. And so forth.<br><br>There is a use case th=
at almost seems legitimate: pure-virtual destructors. It is effectively ide=
ntical to the case of a base class and derived class both needing to do the=
ir part of some work. The difference is that the compiler will <i>ensure</i=
> that all destructors are called.<br><br>But even that is iffy. Why? Becau=
se if the destructor is declared virtual in a base class... why do you need=
 the destructor to be <i>pure</i> virtual? You have no reason to <i>force</=
i> derived classes to implement a destructor. By the rules of C++, having a=
 virtual destructor <i>at all</i> will guarantee that all destructors are c=
alled, in the proper order, when any instance of the class is destroyed thr=
ough a pointer/reference to any type in the hierarchy. If a particular deri=
ved class has no additional cleanup work to do... that&#39;s <i>their busin=
ess</i>. There&#39;s no need to make them write an empty destructor or to e=
xplicitly `=3D default` one.<br><br>I simply don&#39;t see a use case where=
 there isn&#39;t a better alternative.<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/5d514e26-9931-4b4f-90c9-06f3becb1386%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d514e26-9931-4b4f-90c9-06f3becb1386=
%40isocpp.org</a>.<br />

------=_Part_144_523844986.1463583943427--

------=_Part_143_2094277302.1463583943427--

.

On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
> My feelings on the whole idea comes down to this: what does it mean for a
> base class to define a function that is pure-virtual? What is the code
> trying to say about that function? Here's what I mean.

It means that the base class doesn't want to decide how to implement
the functionality,
but can provide a helpful implementation that a derived class can call
if it finds that
implementation suitable. There are articles describing these things,
look for Dobbs/CUJ
treatise of the subject.

> There is a use case that almost seems legitimate: pure-virtual destructors.

It's plenty legitimate if the destructor is the only virtual function
you can make pure.
Such designs occur occasionally.

--
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/CAFk2RUY-C1pRXKVY3oyEcrvbOSjfHn0TJM566-mp4U4mhgGWcg%40mail.gmail.com.

.

--001a113f24f6b54f1605331f57de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 18/5/2016 12:09, "Ville Voutilainen" <ville.voutilainen@gmail.com>
escribi=C3=B3:
>
> On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
> > My feelings on the whole idea comes down to this: what does it mean for
a
> > base class to define a function that is pure-virtual? What is the code
> > trying to say about that function? Here's what I mean.
>
> It means that the base class doesn't want to decide how to implement
> the functionality,
> but can provide a helpful implementation that a derived class can call
> if it finds that
> implementation suitable. There are articles describing these things,
> look for Dobbs/CUJ
> treatise of the subject.

One important use case (and my motivating one) is AOP and responsibilities:
the base aspect performs something and calls a virtual method that all
aspects are obbligated to implement (e.g. processing an event in a chain of
responsibilities), each one passing it to the next aspect (the weaving is
usually implemented with inheritance, usually due to EBCO), finally
reaching the base aspect and the core functionality.

>
> > There is a use case that almost seems legitimate: pure-virtual
destructors.
>
> It's plenty legitimate if the destructor is the only virtual function
> you can make pure.
> Such designs occur occasionally.
>
> --
> 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/CAFk2RUY-C1pRX=
KVY3oyEcrvbOSjfHn0TJM566-mp4U4mhgGWcg%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/CAFdMc-17vK%2BLYJ1JUa6Ye%3Dscghu3L5dWgVwWH-EgEje=
qRb9pvw%40mail.gmail.com.

--001a113f24f6b54f1605331f57de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
El 18/5/2016 12:09, &quot;Ville Voutilainen&quot; &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; escribi=C3=B3=
:<br>
&gt;<br>
&gt; On 18 May 2016 at 18:05, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@g=
mail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; &gt; My feelings on the whole idea comes down to this: what does it me=
an for a<br>
&gt; &gt; base class to define a function that is pure-virtual? What is the=
 code<br>
&gt; &gt; trying to say about that function? Here&#39;s what I mean.<br>
&gt;<br>
&gt; It means that the base class doesn&#39;t want to decide how to impleme=
nt<br>
&gt; the functionality,<br>
&gt; but can provide a helpful implementation that a derived class can call=
<br>
&gt; if it finds that<br>
&gt; implementation suitable. There are articles describing these things,<b=
r>
&gt; look for Dobbs/CUJ<br>
&gt; treatise of the subject.</p>
<p dir=3D"ltr">One important use case (and my motivating one) is AOP and re=
sponsibilities: the base aspect performs something and calls a virtual meth=
od that all aspects are obbligated to implement (e.g. processing an event i=
n a chain of responsibilities), each one passing it to the next aspect (the=
 weaving is usually implemented with inheritance, usually due to EBCO), fin=
ally reaching the base aspect and the core functionality.</p>
<p dir=3D"ltr">&gt;<br>
&gt; &gt; There is a use case that almost seems legitimate: pure-virtual de=
structors.<br>
&gt;<br>
&gt; It&#39;s plenty legitimate if the destructor is the only virtual funct=
ion<br>
&gt; you can make pure.<br>
&gt; Such designs occur occasionally.<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY-C1pRXKVY3oyEcrvbOSjfHn0=
TJM566-mp4U4mhgGWcg%40mail.gmail.com">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAFk2RUY-C1pRXKVY3oyEcrvbOSjfHn0TJM566-mp4U4mhgGWcg=
%40mail.gmail.com</a>.<br>
</p>

<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/CAFdMc-17vK%2BLYJ1JUa6Ye%3Dscghu3L5dW=
gVwWH-EgEjeqRb9pvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-17vK%2=
BLYJ1JUa6Ye%3Dscghu3L5dWgVwWH-EgEjeqRb9pvw%40mail.gmail.com</a>.<br />

--001a113f24f6b54f1605331f57de--

.

------=_Part_230_328241307.1463585452005
Content-Type: multipart/alternative;
 boundary="----=_Part_231_1076325907.1463585452005"

------=_Part_231_1076325907.1463585452005
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 18, 2016 at 11:09:46 AM UTC-4, Ville Voutilainen wrote:
>
> On 18 May 2016 at 18:05, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > My feelings on the whole idea comes down to this: what does it mean for
> a
> > base class to define a function that is pure-virtual? What is the code
> > trying to say about that function? Here's what I mean.
>
> It means that the base class doesn't want to decide how to implement
> the functionality,
> but can provide a helpful implementation that a derived class can call
> if it finds that
> implementation suitable.


Yes, and as I explained, you can do that without using a function who's
name and interface match the overridden one. So there is no specific *need*
for this feature; you can get the job done without it.

And I still submit that it would be better to give such a function a
different name, simply to better express what it is doing (or more to the
point, what it *isn't* doing).

There are articles describing these things,
> look for Dobbs/CUJ
> treatise of the subject.
>
> > There is a use case that almost seems legitimate: pure-virtual
> destructors.
>
> It's plenty legitimate if the destructor is the only virtual function
> you can make pure.
> Such designs occur occasionally.
>

A class where the only pure virtual function is a defined destructor is a
perfectly functional class otherwise. It can be constructed. Every method
can be called with logical and consistent results. The destructor exists
and has reasonable behavior. And so forth. In every way, it is a complete
class.

If the base class doesn't really do anything, if it's simply an interface
who's functions are stubs (so that derived classes don't have to implement
them)... what's the *harm* in creating an instance of just the base class?
Why would the writer of a class feel the need to *prevent* it?

I don't feel that syntax should be spent to prevent people from doing
harmless things.

--
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/97c776cf-b01d-440e-ab47-51923b0cc0d3%40isocpp.org.

------=_Part_231_1076325907.1463585452005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, May 18, 2016 at 11:09:46 AM UTC-4, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 May 2016 =
at 18:05, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"7-AKzBhwCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; My feelings on the whole idea comes down to this: what does it mea=
n for a
<br>&gt; base class to define a function that is pure-virtual? What is the =
code
<br>&gt; trying to say about that function? Here&#39;s what I mean.
<br>
<br>It means that the base class doesn&#39;t want to decide how to implemen=
t
<br>the functionality,
<br>but can provide a helpful implementation that a derived class can call
<br>if it finds that
<br>implementation suitable.</blockquote><div><br>Yes, and as I explained, =
you can do that without using a function who&#39;s name and interface match=
 the overridden one. So there is no specific <i>need</i> for this feature; =
you can get the job done without it.<br><br>And I still submit that it woul=
d be better to give such a function a different name, simply to better expr=
ess what it is doing (or more to the point, what it <i>isn&#39;t</i> doing)=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> There are arti=
cles describing these things,
<br>look for Dobbs/CUJ
<br>treatise of the subject.
<br>
<br>&gt; There is a use case that almost seems legitimate: pure-virtual des=
tructors.
<br>
<br>It&#39;s plenty legitimate if the destructor is the only virtual functi=
on
<br>you can make pure.
<br>Such designs occur occasionally.<br></blockquote><div><br>A class where=
 the only pure virtual function is a defined destructor is a perfectly func=
tional class otherwise. It can be constructed. Every method can be called w=
ith logical and consistent results. The destructor exists and has reasonabl=
e behavior. And so forth. In every way, it is a complete class.<br><br>If t=
he base class doesn&#39;t really do anything, if it&#39;s simply an interfa=
ce who&#39;s functions are stubs (so that derived classes don&#39;t have to=
 implement them)... what&#39;s the <i>harm</i> in creating an instance of j=
ust the base class? Why would the writer of a class feel the need to <i>pre=
vent</i> it?<br><br>I don&#39;t feel that syntax should be spent to prevent=
 people from doing harmless things.<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/97c776cf-b01d-440e-ab47-51923b0cc0d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97c776cf-b01d-440e-ab47-51923b0cc0d3=
%40isocpp.org</a>.<br />

------=_Part_231_1076325907.1463585452005--

------=_Part_230_328241307.1463585452005--

.

On Wed, May 18, 2016 at 12:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, May 18, 2016 at 11:09:46 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 18 May 2016 at 18:05, Nicol Bolas <jmck...@gmail.com> wrote:
>> > My feelings on the whole idea comes down to this: what does it mean fo=
r
>> > a
>> > base class to define a function that is pure-virtual? What is the code
>> > trying to say about that function? Here's what I mean.
>>
>> It means that the base class doesn't want to decide how to implement
>> the functionality,
>> but can provide a helpful implementation that a derived class can call
>> if it finds that
>> implementation suitable.
>
>
> Yes, and as I explained, you can do that without using a function who's n=
ame
> and interface match the overridden one. So there is no specific need for
> this feature; you can get the job done without it.
>
> And I still submit that it would be better to give such a function a
> different name, simply to better express what it is doing (or more to the
> point, what it isn't doing).
>
>> There are articles describing these things,
>> look for Dobbs/CUJ
>> treatise of the subject.
>>
>> > There is a use case that almost seems legitimate: pure-virtual
>> > destructors.
>>
>> It's plenty legitimate if the destructor is the only virtual function
>> you can make pure.
>> Such designs occur occasionally.
>
>
> A class where the only pure virtual function is a defined destructor is a
> perfectly functional class otherwise. It can be constructed. Every method
> can be called with logical and consistent results. The destructor exists =
and
> has reasonable behavior. And so forth. In every way, it is a complete cla=
ss.
>
> If the base class doesn't really do anything, if it's simply an interface
> who's functions are stubs (so that derived classes don't have to implemen=
t
> them)... what's the harm in creating an instance of just the base class? =
Why
> would the writer of a class feel the need to prevent it?


This is an example of a real-life project (stripped down and somewhat alter=
ed).
It's a system-wide multiple board debugger.
http://ideone.com/ZhRi7A

>
> I don't feel that syntax should be spent to prevent people from doing
> harmless things.
>
> --
> 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/97c776cf-b01=
d-440e-ab47-51923b0cc0d3%40isocpp.org.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2PaMHAQhurgxUJYGPsyGAFxAaxsEWLe4gTUuCDOVz=
GWg%40mail.gmail.com.

.

On quarta-feira, 18 de maio de 2016 07:24:57 PDT Nicol Bolas wrote:
> But from a "good for the language" standpoint, the fact that defining
> pure-virtual methods is not a good feature is *precisely why* we shouldn't
> allow inline definitions. We don't want to legitimize a misfeature by
> making it more usable.

But if that's the case, how are we going to get our "protected abstract
virtual base pure virtual private destructors"?

--
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/7670506.TaFrl12L6R%40tjmaciei-mobl1.

.

--001a11355f4277495f053326864e
Content-Type: text/plain; charset=UTF-8

On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
> > My feelings on the whole idea comes down to this: what does it mean for a
> > base class to define a function that is pure-virtual? What is the code
> > trying to say about that function? Here's what I mean.
>
> It means that the base class doesn't want to decide how to implement
> the functionality,
> but can provide a helpful implementation that a derived class can call
> if it finds that
> implementation suitable. There are articles describing these things,
> look for Dobbs/CUJ
> treatise of the subject.
>
> > There is a use case that almost seems legitimate: pure-virtual
> destructors.
>
> It's plenty legitimate if the destructor is the only virtual function
> you can make pure.
> Such designs occur occasionally.


Right. But in such cases, declaring the destructor as pure virtual is a
hack; if we want better language support for such designs, we should allow
a class to be made abstract despite not having pure virtual member
functions. Personally, I think committee cycles would be better spent on
adding an [[abstract]] attribute rather than supporting virtual =0 {}
syntax.

--
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/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com.

--001a11355f4277495f053326864e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 18, 2016 at 8:09 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 18 May 2016 at 18:05, Nicol Bolas &lt;<a href=3D"mailto:jmckes=
son@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; My feelings on the whole idea comes down to this: what does it mean fo=
r a<br>
&gt; base class to define a function that is pure-virtual? What is the code=
<br>
&gt; trying to say about that function? Here&#39;s what I mean.<br>
<br>
</span>It means that the base class doesn&#39;t want to decide how to imple=
ment<br>
the functionality,<br>
but can provide a helpful implementation that a derived class can call<br>
if it finds that<br>
implementation suitable. There are articles describing these things,<br>
look for Dobbs/CUJ<br>
treatise of the subject.<br>
<span class=3D""><br>
&gt; There is a use case that almost seems legitimate: pure-virtual destruc=
tors.<br>
<br>
</span>It&#39;s plenty legitimate if the destructor is the only virtual fun=
ction<br>
you can make pure.<br>
Such designs occur occasionally.</blockquote><div><br></div><div>Right. But=
 in such cases, declaring the destructor as pure virtual is a hack; if we w=
ant better language support for such designs, we should allow a class to be=
 made abstract despite not having pure virtual member functions. Personally=
, I think committee cycles would be better spent on adding an [[abstract]] =
attribute rather than supporting virtual =3D0 {} syntax.</div></div></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/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9s=
Doo19x46V-abbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8t=
S2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com</a>.<br />

--001a11355f4277495f053326864e--

.

On 19 May 2016 at 02:50, Richard Smith <richard@metafoo.co.uk> wrote:
>> > There is a use case that almost seems legitimate: pure-virtual
>> > destructors.
>>
>> It's plenty legitimate if the destructor is the only virtual function
>> you can make pure.
>> Such designs occur occasionally.
>
>
> Right. But in such cases, declaring the destructor as pure virtual is a
> hack; if we want better language support for such designs, we should allow a
> class to be made abstract despite not having pure virtual member functions.
> Personally, I think committee cycles would be better spent on adding an
> [[abstract]] attribute rather than supporting virtual =0 {} syntax.

Yay, I can only imagine the amount of committee cycles that we'll burn rehashing
the whole "should attributes have semantic effect" discussion, and considering
a context-sensitive keyword instead. Implementation-wise and specification-wise
both of those alternatives are something both of us can do over a coffee break.

However, if you're trying to convince me with clever nuance that the
whole facility
is not worth having, you have succeeded with flying colors. The hack
won't go away,
but we'll have yet another way to mark a class as abstract, and we're
not helping
Daniel's use case in any way. That use case is arguably rare, so I'm
not convinced
we need to help it.

--
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/CAFk2RUabjN%3DxNhZWDiHU6yX6HD-hjTvw9-GFs_8fUdQ3W9VQLA%40mail.gmail.com.

.

--001a114e19f87cba52053326d7fc
Content-Type: text/plain; charset=UTF-8

Hum. Wouldn't [[abstract]] suggest the compiler can see it as a suggestion
rather than a constraint?

2016-05-18 19:50 GMT-04:00 Richard Smith <richard@metafoo.co.uk>:

> On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
>> > My feelings on the whole idea comes down to this: what does it mean for
>> a
>> > base class to define a function that is pure-virtual? What is the code
>> > trying to say about that function? Here's what I mean.
>>
>> It means that the base class doesn't want to decide how to implement
>> the functionality,
>> but can provide a helpful implementation that a derived class can call
>> if it finds that
>> implementation suitable. There are articles describing these things,
>> look for Dobbs/CUJ
>> treatise of the subject.
>>
>> > There is a use case that almost seems legitimate: pure-virtual
>> destructors.
>>
>> It's plenty legitimate if the destructor is the only virtual function
>> you can make pure.
>> Such designs occur occasionally.
>
>
> Right. But in such cases, declaring the destructor as pure virtual is a
> hack; if we want better language support for such designs, we should allow
> a class to be made abstract despite not having pure virtual member
> functions. Personally, I think committee cycles would be better spent on
> adding an [[abstract]] attribute rather than supporting virtual =0 {}
> syntax.
>
> --
> 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/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com.

--001a114e19f87cba52053326d7fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hum. Wouldn&#39;t [[abstract]] suggest the compiler can se=
e it as a suggestion rather than a constraint?<br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">2016-05-18 19:50 GMT-04:00 Richard S=
mith <span dir=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=
=3D"_blank">richard@metafoo.co.uk</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><span class=3D"">On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=
=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span>On 18 May 2016 at 18:05, Nicol Bolas &lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t; wrote:<br>
&gt; My feelings on the whole idea comes down to this: what does it mean fo=
r a<br>
&gt; base class to define a function that is pure-virtual? What is the code=
<br>
&gt; trying to say about that function? Here&#39;s what I mean.<br>
<br>
</span>It means that the base class doesn&#39;t want to decide how to imple=
ment<br>
the functionality,<br>
but can provide a helpful implementation that a derived class can call<br>
if it finds that<br>
implementation suitable. There are articles describing these things,<br>
look for Dobbs/CUJ<br>
treatise of the subject.<br>
<span><br>
&gt; There is a use case that almost seems legitimate: pure-virtual destruc=
tors.<br>
<br>
</span>It&#39;s plenty legitimate if the destructor is the only virtual fun=
ction<br>
you can make pure.<br>
Such designs occur occasionally.</blockquote><div><br></div></span><div>Rig=
ht. But in such cases, declaring the destructor as pure virtual is a hack; =
if we want better language support for such designs, we should allow a clas=
s to be made abstract despite not having pure virtual member functions. Per=
sonally, I think committee cycles would be better spent on adding an [[abst=
ract]] attribute rather than supporting virtual =3D0 {} syntax.</div></div>=
</div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9s=
Doo19x46V-abbg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></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/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKS=
bxcM41xV9SkgxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zn=
gETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com</a>.<br />

--001a114e19f87cba52053326d7fc--

.

On 19 May 2016 at 03:13, Patrice Roy <patricer@gmail.com> wrote:
> Hum. Wouldn't [[abstract]] suggest the compiler can see it as a suggestion
> rather than a constraint?


Here we go. :)

--
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/CAFk2RUa0%2BNOxooO3FRzjJKaKHfh%3DtbrGrWW%2B-Aq%3D7%3DBeznbMqg%40mail.gmail.com.

.

--94eb2c047d7a0b139e053326e4da
Content-Type: text/plain; charset=UTF-8

Our messages crossed each other :)

2016-05-18 20:14 GMT-04:00 Ville Voutilainen <ville.voutilainen@gmail.com>:

> On 19 May 2016 at 03:13, Patrice Roy <patricer@gmail.com> wrote:
> > Hum. Wouldn't [[abstract]] suggest the compiler can see it as a
> suggestion
> > rather than a constraint?
>
>
> Here we go. :)
>
> --
> 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/CAFk2RUa0%2BNOxooO3FRzjJKaKHfh%3DtbrGrWW%2B-Aq%3D7%3DBeznbMqg%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/isocpp.org/d/msgid/std-proposals/CAKiZDp0ZhtRL%3D6p9095U%3DLKN%2B7oTaBDEuTsSDP48Dx2UKV77LA%40mail.gmail.com.

--94eb2c047d7a0b139e053326e4da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Our messages crossed each other :)<br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">2016-05-18 20:14 GMT-04:00 Vill=
e Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gma=
il.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span>:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">On 19 May 2016 at 03:13, Patr=
ice Roy &lt;<a href=3D"mailto:patricer@gmail.com">patricer@gmail.com</a>&gt=
; wrote:<br>
&gt; Hum. Wouldn&#39;t [[abstract]] suggest the compiler can see it as a su=
ggestion<br>
&gt; rather than a constraint?<br>
<br>
<br>
</span>Here we go. :)<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa0%2BNOxooO3FRzjJKaKHfh=
%3DtbrGrWW%2B-Aq%3D7%3DBeznbMqg%40mail.gmail.com" rel=3D"noreferrer" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA=
Fk2RUa0%2BNOxooO3FRzjJKaKHfh%3DtbrGrWW%2B-Aq%3D7%3DBeznbMqg%40mail.gmail.co=
m</a>.<br>
</blockquote></div><br></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/CAKiZDp0ZhtRL%3D6p9095U%3DLKN%2B7oTaB=
DEuTsSDP48Dx2UKV77LA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0Zht=
RL%3D6p9095U%3DLKN%2B7oTaBDEuTsSDP48Dx2UKV77LA%40mail.gmail.com</a>.<br />

--94eb2c047d7a0b139e053326e4da--

.

--001a114ca0384d6b14053326fb29
Content-Type: text/plain; charset=UTF-8

On Wed, May 18, 2016 at 5:13 PM, Patrice Roy <patricer@gmail.com> wrote:

> Hum. Wouldn't [[abstract]] suggest the compiler can see it as a suggestion
> rather than a constraint?
>

Yes, a low-quality conforming C++2{ compiler could choose to issue a
diagnostic when it sees the attribute and then (outside of SFINAE contexts)
compile the rest of the program ignoring its presence. In exactly the same
way, a low-quality conforming C++1z compiler could choose to issue a
diagnostic when it sees a =0, and then (outside of SFINAE contexts) not
diagnose uses of the class that are ill-formed only because it's abstract.
If you don't use low-quality implementations, the problem goes away.

Alternatively, you could handle it as a context-sensitive keyword like
'final'. The point is that it's something you specify on the class, not on
some arbitrarily-chosen member function.

2016-05-18 19:50 GMT-04:00 Richard Smith <richard@metafoo.co.uk>:
>
>> On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen <
>> ville.voutilainen@gmail.com> wrote:
>>
>>> On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> > My feelings on the whole idea comes down to this: what does it mean
>>> for a
>>> > base class to define a function that is pure-virtual? What is the code
>>> > trying to say about that function? Here's what I mean.
>>>
>>> It means that the base class doesn't want to decide how to implement
>>> the functionality,
>>> but can provide a helpful implementation that a derived class can call
>>> if it finds that
>>> implementation suitable. There are articles describing these things,
>>> look for Dobbs/CUJ
>>> treatise of the subject.
>>>
>>> > There is a use case that almost seems legitimate: pure-virtual
>>> destructors.
>>>
>>> It's plenty legitimate if the destructor is the only virtual function
>>> you can make pure.
>>> Such designs occur occasionally.
>>
>>
>> Right. But in such cases, declaring the destructor as pure virtual is a
>> hack; if we want better language support for such designs, we should allow
>> a class to be made abstract despite not having pure virtual member
>> functions. Personally, I think committee cycles would be better spent on
>> adding an [[abstract]] attribute rather than supporting virtual =0 {}
>> syntax.
>>
>> --
>> 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/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com.

--001a114ca0384d6b14053326fb29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 18, 2016 at 5:13 PM, Patrice Roy <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hum. Wouldn&#3=
9;t [[abstract]] suggest the compiler can see it as a suggestion rather tha=
n a constraint?</div></blockquote><div><br></div><div>Yes, a low-quality co=
nforming C++2{ compiler could choose to issue a diagnostic when it sees the=
 attribute and then (outside of SFINAE contexts) compile the rest of the pr=
ogram ignoring its presence. In exactly the same way, a low-quality conform=
ing C++1z compiler could choose to issue a diagnostic when it sees a =3D0, =
and then (outside of SFINAE contexts) not diagnose uses of the class that a=
re ill-formed only because it&#39;s abstract. If you don&#39;t use low-qual=
ity implementations, the problem goes away.</div><div><br></div><div>Altern=
atively, you could handle it as a context-sensitive keyword like &#39;final=
&#39;. The point is that it&#39;s something you specify on the class, not o=
n some arbitrarily-chosen member function.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv><div class=3D"h5">2016-05-18 19:50 GMT-04:00 Richard Smith <span dir=3D"=
ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard=
@metafoo.co.uk</a>&gt;</span>:<br></div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><span>On Wed, May 18, 2016 at 8:09 AM, Ville Voutilain=
en <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" tar=
get=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span>On 18 May 2016 at 18:05, Nicol Bolas &lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt; wrote:<br>
&gt; My feelings on the whole idea comes down to this: what does it mean fo=
r a<br>
&gt; base class to define a function that is pure-virtual? What is the code=
<br>
&gt; trying to say about that function? Here&#39;s what I mean.<br>
<br>
</span>It means that the base class doesn&#39;t want to decide how to imple=
ment<br>
the functionality,<br>
but can provide a helpful implementation that a derived class can call<br>
if it finds that<br>
implementation suitable. There are articles describing these things,<br>
look for Dobbs/CUJ<br>
treatise of the subject.<br>
<span><br>
&gt; There is a use case that almost seems legitimate: pure-virtual destruc=
tors.<br>
<br>
</span>It&#39;s plenty legitimate if the destructor is the only virtual fun=
ction<br>
you can make pure.<br>
Such designs occur occasionally.</blockquote><div><br></div></span><div>Rig=
ht. But in such cases, declaring the destructor as pure virtual is a hack; =
if we want better language support for such designs, we should allow a clas=
s to be made abstract despite not having pure virtual member functions. Per=
sonally, I think committee cycles would be better spent on adding an [[abst=
ract]] attribute rather than supporting virtual =3D0 {} syntax.</div></div>=
</div></div></div></div><span>

<p></p>

-- <br><span class=3D"">
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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9s=
Doo19x46V-abbg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKS=
bxcM41xV9SkgxA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com</=
a>.<br>
</blockquote></div><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/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp=
-Ss7cCGe5SDhpjZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnrc7_3Lh=
amPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com</a>.<br />

--001a114ca0384d6b14053326fb29--

.

--001a11447598d2e50e0533274344
Content-Type: text/plain; charset=UTF-8

Interesting.I thought the =0 was mandatory whereas the [[abstract]] was a
non-semantics-affecting suggestion. My reading of the current standard text
is that pure-specifiers are mandatory elements. Am I missing something?

2016-05-18 20:23 GMT-04:00 Richard Smith <richard@metafoo.co.uk>:

> On Wed, May 18, 2016 at 5:13 PM, Patrice Roy <patricer@gmail.com> wrote:
>
>> Hum. Wouldn't [[abstract]] suggest the compiler can see it as a
>> suggestion rather than a constraint?
>>
>
> Yes, a low-quality conforming C++2{ compiler could choose to issue a
> diagnostic when it sees the attribute and then (outside of SFINAE contexts)
> compile the rest of the program ignoring its presence. In exactly the same
> way, a low-quality conforming C++1z compiler could choose to issue a
> diagnostic when it sees a =0, and then (outside of SFINAE contexts) not
> diagnose uses of the class that are ill-formed only because it's abstract.
> If you don't use low-quality implementations, the problem goes away.
>
> Alternatively, you could handle it as a context-sensitive keyword like
> 'final'. The point is that it's something you specify on the class, not on
> some arbitrarily-chosen member function.
>
> 2016-05-18 19:50 GMT-04:00 Richard Smith <richard@metafoo.co.uk>:
>>
>>> On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen <
>>> ville.voutilainen@gmail.com> wrote:
>>>
>>>> On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
>>>> > My feelings on the whole idea comes down to this: what does it mean
>>>> for a
>>>> > base class to define a function that is pure-virtual? What is the code
>>>> > trying to say about that function? Here's what I mean.
>>>>
>>>> It means that the base class doesn't want to decide how to implement
>>>> the functionality,
>>>> but can provide a helpful implementation that a derived class can call
>>>> if it finds that
>>>> implementation suitable. There are articles describing these things,
>>>> look for Dobbs/CUJ
>>>> treatise of the subject.
>>>>
>>>> > There is a use case that almost seems legitimate: pure-virtual
>>>> destructors.
>>>>
>>>> It's plenty legitimate if the destructor is the only virtual function
>>>> you can make pure.
>>>> Such designs occur occasionally.
>>>
>>>
>>> Right. But in such cases, declaring the destructor as pure virtual is a
>>> hack; if we want better language support for such designs, we should allow
>>> a class to be made abstract despite not having pure virtual member
>>> functions. Personally, I think committee cycles would be better spent on
>>> adding an [[abstract]] attribute rather than supporting virtual =0 {}
>>> syntax.
>>>
>>> --
>>> 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/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> 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/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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/CAKiZDp3ahcepkwA6AXtRd8p2ia09jpoZkw0vxvGU%3DBD6WsmwAA%40mail.gmail.com.

--001a11447598d2e50e0533274344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Interesting.I thought the =3D0 was mandatory whereas the [=
[abstract]] was a non-semantics-affecting suggestion. My reading of the cur=
rent standard text is that pure-specifiers are mandatory elements. Am I mis=
sing something?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">2016-05-18 20:23 GMT-04:00 Richard Smith <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.u=
k</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Ma=
y 18, 2016 at 5:13 PM, Patrice Roy <span dir=3D"ltr">&lt;<a href=3D"mailto:=
patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hum. Wouldn&#39;t [[=
abstract]] suggest the compiler can see it as a suggestion rather than a co=
nstraint?</div></blockquote><div><br></div></span><div>Yes, a low-quality c=
onforming C++2{ compiler could choose to issue a diagnostic when it sees th=
e attribute and then (outside of SFINAE contexts) compile the rest of the p=
rogram ignoring its presence. In exactly the same way, a low-quality confor=
ming C++1z compiler could choose to issue a diagnostic when it sees a =3D0,=
 and then (outside of SFINAE contexts) not diagnose uses of the class that =
are ill-formed only because it&#39;s abstract. If you don&#39;t use low-qua=
lity implementations, the problem goes away.</div><div><br></div><div>Alter=
natively, you could handle it as a context-sensitive keyword like &#39;fina=
l&#39;. The point is that it&#39;s something you specify on the class, not =
on some arbitrarily-chosen member function.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><div class=3D"h5"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><div>2016-05-18 19:50 GMT-04:00 Richard Smith <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_bla=
nk">richard@metafoo.co.uk</a>&gt;</span>:<br></div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span>On Wed, May 18, 2016 at 8:09 AM, Ville Voutilaine=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" targ=
et=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span>On 18 May 2016 at 18:05, Nicol Bolas &lt;<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>=
&gt; wrote:<br>
&gt; My feelings on the whole idea comes down to this: what does it mean fo=
r a<br>
&gt; base class to define a function that is pure-virtual? What is the code=
<br>
&gt; trying to say about that function? Here&#39;s what I mean.<br>
<br>
</span>It means that the base class doesn&#39;t want to decide how to imple=
ment<br>
the functionality,<br>
but can provide a helpful implementation that a derived class can call<br>
if it finds that<br>
implementation suitable. There are articles describing these things,<br>
look for Dobbs/CUJ<br>
treatise of the subject.<br>
<span><br>
&gt; There is a use case that almost seems legitimate: pure-virtual destruc=
tors.<br>
<br>
</span>It&#39;s plenty legitimate if the destructor is the only virtual fun=
ction<br>
you can make pure.<br>
Such designs occur occasionally.</blockquote><div><br></div></span><div>Rig=
ht. But in such cases, declaring the destructor as pure virtual is a hack; =
if we want better language support for such designs, we should allow a clas=
s to be made abstract despite not having pure virtual member functions. Per=
sonally, I think committee cycles would be better spent on adding an [[abst=
ract]] attribute rather than supporting virtual =3D0 {} syntax.</div></div>=
</div></div></div></div><span>

<p></p>

-- <br><span>
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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9s=
Doo19x46V-abbg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></div><span>

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span></div></div=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKS=
bxcM41xV9SkgxA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp=
-Ss7cCGe5SDhpjZg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br></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/CAKiZDp3ahcepkwA6AXtRd8p2ia09jpoZkw0v=
xvGU%3DBD6WsmwAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3ahcepkw=
A6AXtRd8p2ia09jpoZkw0vxvGU%3DBD6WsmwAA%40mail.gmail.com</a>.<br />

--001a11447598d2e50e0533274344--

.

On quarta-feira, 18 de maio de 2016 17:23:21 PDT Richard Smith wrote:
> Yes, a low-quality conforming C++2{ compiler could choose to issue a
> diagnostic when it sees the attribute and then (outside of SFINAE contexts)
> compile the rest of the program ignoring its presence.

But fail to link.

Since this is a virtual function, it must be listed in the vtable. If the
compiler ignored the [[abstract]] attribute, it won't know to insert the
marker for pure virtual functions. Instead, it will try to find the actual
function's entry point, which may not exist.

--
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/28706525.jxcsXmKXrz%40tjmaciei-mobl1.

.

--001a114ca03866f7ba05332c6094
Content-Type: text/plain; charset=UTF-8

On 18 May 2016 11:31 p.m., "Thiago Macieira" <thiago@macieira.org> wrote:
>
> On quarta-feira, 18 de maio de 2016 17:23:21 PDT Richard Smith wrote:
> > Yes, a low-quality conforming C++2{ compiler could choose to issue a
> > diagnostic when it sees the attribute and then (outside of SFINAE
contexts)
> > compile the rest of the program ignoring its presence.
>
> But fail to link.
>
> Since this is a virtual function, it must be listed in the vtable. If the
> compiler ignored the [[abstract]] attribute, it won't know to insert the
> marker for pure virtual functions. Instead, it will try to find the actual
> function's entry point, which may not exist.

What pure virtual function?

> --
> 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/28706525.jxcsXmKXrz%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/CAOfiQq%3DMXY6UozVp66hq-q_grnQEpM6fYsZ8zzvGYcWfJ9dqVQ%40mail.gmail.com.

--001a114ca03866f7ba05332c6094
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 18 May 2016 11:31 p.m., &quot;Thiago Macieira&quot; &lt;<=
a href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br=
>
&gt;<br>
&gt; On quarta-feira, 18 de maio de 2016 17:23:21 PDT Richard Smith wrote:<=
br>
&gt; &gt; Yes, a low-quality conforming C++2{ compiler could choose to issu=
e a<br>
&gt; &gt; diagnostic when it sees the attribute and then (outside of SFINAE=
 contexts)<br>
&gt; &gt; compile the rest of the program ignoring its presence.<br>
&gt;<br>
&gt; But fail to link.<br>
&gt;<br>
&gt; Since this is a virtual function, it must be listed in the vtable. If =
the<br>
&gt; compiler ignored the [[abstract]] attribute, it won&#39;t know to inse=
rt the<br>
&gt; marker for pure virtual functions. Instead, it will try to find the ac=
tual<br>
&gt; function&#39;s entry point, which may not exist.</p>
<p dir=3D"ltr">What pure virtual function?</p>
<p dir=3D"ltr">&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/28706525.jxcsXmKXrz%40tjmaciei-m=
obl1">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/28706525=
..jxcsXmKXrz%40tjmaciei-mobl1</a>.<br>
</p>

<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/CAOfiQq%3DMXY6UozVp66hq-q_grnQEpM6fYs=
Z8zzvGYcWfJ9dqVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DMXY6U=
ozVp66hq-q_grnQEpM6fYsZ8zzvGYcWfJ9dqVQ%40mail.gmail.com</a>.<br />

--001a114ca03866f7ba05332c6094--

.

2016-05-19 2:14 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 19 May 2016 at 03:13, Patrice Roy <patricer@gmail.com> wrote:
>> Hum. Wouldn't [[abstract]] suggest the compiler can see it as a suggestion
>> rather than a constraint?
>
> Here we go. :)

Similar to override and final it should be a context-sensitive
keyword, as Richard suggested.

- Daniel

--
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/CAGNvRgC7uTFkgEU9gfdPT1khWEQ%3D62UoMn5X0jfLSMbDyS6eKg%40mail.gmail.com.

.

------=_Part_1174_1540360110.1463683443655
Content-Type: multipart/alternative;
 boundary="----=_Part_1175_1331672094.1463683443655"

------=_Part_1175_1331672094.1463683443655
Content-Type: text/plain; charset=UTF-8

On Wednesday, May 18, 2016 at 12:19:00 PM UTC-4, dgutson wrote:
>
> On Wed, May 18, 2016 at 12:30 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Wednesday, May 18, 2016 at 11:09:46 AM UTC-4, Ville Voutilainen
> wrote:
> >>
> >> On 18 May 2016 at 18:05, Nicol Bolas <jmck...@gmail.com> wrote:
> >> > My feelings on the whole idea comes down to this: what does it mean
> for
> >> > a
> >> > base class to define a function that is pure-virtual? What is the
> code
> >> > trying to say about that function? Here's what I mean.
> >>
> >> It means that the base class doesn't want to decide how to implement
> >> the functionality,
> >> but can provide a helpful implementation that a derived class can call
> >> if it finds that
> >> implementation suitable.
> >
> >
> > Yes, and as I explained, you can do that without using a function who's
> name
> > and interface match the overridden one. So there is no specific need for
> > this feature; you can get the job done without it.
> >
> > And I still submit that it would be better to give such a function a
> > different name, simply to better express what it is doing (or more to
> the
> > point, what it isn't doing).
> >
> >> There are articles describing these things,
> >> look for Dobbs/CUJ
> >> treatise of the subject.
> >>
> >> > There is a use case that almost seems legitimate: pure-virtual
> >> > destructors.
> >>
> >> It's plenty legitimate if the destructor is the only virtual function
> >> you can make pure.
> >> Such designs occur occasionally.
> >
> >
> > A class where the only pure virtual function is a defined destructor is
> a
> > perfectly functional class otherwise. It can be constructed. Every
> method
> > can be called with logical and consistent results. The destructor exists
> and
> > has reasonable behavior. And so forth. In every way, it is a complete
> class.
> >
> > If the base class doesn't really do anything, if it's simply an
> interface
> > who's functions are stubs (so that derived classes don't have to
> implement
> > them)... what's the harm in creating an instance of just the base class?
> Why
> > would the writer of a class feel the need to prevent it?
>
>
> This is an example of a real-life project (stripped down and somewhat
> altered).
> It's a system-wide multiple board debugger.
> http://ideone.com/ZhRi7A
>

That's an interesting example. The idea behind it is to turn what would
have been an unrecoverable runtime error (calling a function that doesn't
exist) into a recoverable runtime exception.

I just can't help thinking however that your problem would be solved just
as effectively via template metaprogramming and static dispatch. After all,
the sequence of types in question is fixed at compile time. Which means
that the sequence of objects who will be processed in order is fixed at
compile time. The return value of each "aspect" could tell you whether to
process the next one. And if there isn't a next one, you throw an exception.

It seems odd that you would choose virtual functions to solve this problem,
when everything conceptually could be done at compile-time. The only place
where you even use virtual dispatch is in `BaseAspect::runInferior`. That
could probably be handled via the CRTP.

I admit however that I haven't thought particularly deeply about the
problem.

--
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/083e2176-c037-4171-abb4-8b46d016a28c%40isocpp.org.

------=_Part_1175_1331672094.1463683443655
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, May 18, 2016 at 12:19:00 PM UTC-4, dgutson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, May 18, 2016 at 1=
2:30 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"1B-ZBuBzCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Wednesday, May 18, 2016 at 11:09:46 AM UTC-4, Ville Voutilainen=
 wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 18 May 2016 at 18:05, Nicol Bolas &lt;<a>jmck...@gmail.com<=
/a>&gt; wrote:
<br>&gt;&gt; &gt; My feelings on the whole idea comes down to this: what do=
es it mean for
<br>&gt;&gt; &gt; a
<br>&gt;&gt; &gt; base class to define a function that is pure-virtual? Wha=
t is the code
<br>&gt;&gt; &gt; trying to say about that function? Here&#39;s what I mean=
..
<br>&gt;&gt;
<br>&gt;&gt; It means that the base class doesn&#39;t want to decide how to=
 implement
<br>&gt;&gt; the functionality,
<br>&gt;&gt; but can provide a helpful implementation that a derived class =
can call
<br>&gt;&gt; if it finds that
<br>&gt;&gt; implementation suitable.
<br>&gt;
<br>&gt;
<br>&gt; Yes, and as I explained, you can do that without using a function =
who&#39;s name
<br>&gt; and interface match the overridden one. So there is no specific ne=
ed for
<br>&gt; this feature; you can get the job done without it.
<br>&gt;
<br>&gt; And I still submit that it would be better to give such a function=
 a
<br>&gt; different name, simply to better express what it is doing (or more=
 to the
<br>&gt; point, what it isn&#39;t doing).
<br>&gt;
<br>&gt;&gt; There are articles describing these things,
<br>&gt;&gt; look for Dobbs/CUJ
<br>&gt;&gt; treatise of the subject.
<br>&gt;&gt;
<br>&gt;&gt; &gt; There is a use case that almost seems legitimate: pure-vi=
rtual
<br>&gt;&gt; &gt; destructors.
<br>&gt;&gt;
<br>&gt;&gt; It&#39;s plenty legitimate if the destructor is the only virtu=
al function
<br>&gt;&gt; you can make pure.
<br>&gt;&gt; Such designs occur occasionally.
<br>&gt;
<br>&gt;
<br>&gt; A class where the only pure virtual function is a defined destruct=
or is a
<br>&gt; perfectly functional class otherwise. It can be constructed. Every=
 method
<br>&gt; can be called with logical and consistent results. The destructor =
exists and
<br>&gt; has reasonable behavior. And so forth. In every way, it is a compl=
ete class.
<br>&gt;
<br>&gt; If the base class doesn&#39;t really do anything, if it&#39;s simp=
ly an interface
<br>&gt; who&#39;s functions are stubs (so that derived classes don&#39;t h=
ave to implement
<br>&gt; them)... what&#39;s the harm in creating an instance of just the b=
ase class? Why
<br>&gt; would the writer of a class feel the need to prevent it?
<br>
<br>
<br>This is an example of a real-life project (stripped down and somewhat a=
ltered).
<br>It&#39;s a system-wide multiple board debugger.
<br><a href=3D"http://ideone.com/ZhRi7A" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fideone.com%2FZhRi7A\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFGjjtPAoCuQu7=
ZHMaD7QvBiSouVg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fideone.com%2FZhRi7A\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNFGjjtPAoCuQu7ZHMaD7QvBiSouVg&#39;;return true;">http://ide=
one.com/ZhRi7A</a>
<br></blockquote><div><br>That&#39;s an interesting example. The idea behin=
d it is to turn what would have been an unrecoverable runtime error (callin=
g a function that doesn&#39;t exist) into a recoverable runtime exception.<=
br><br>I just can&#39;t help thinking however that your problem would be so=
lved just as effectively via template metaprogramming and static dispatch. =
After all, the sequence of types in question is fixed at compile time. Whic=
h means that the sequence of objects who will be processed in order is fixe=
d at compile time. The return value of each &quot;aspect&quot; could tell y=
ou whether to process the next one. And if there isn&#39;t a next one, you =
throw an exception.<br><br>It seems odd that you would choose virtual funct=
ions to solve this problem, when everything conceptually could be done at c=
ompile-time. The only place where you even use virtual dispatch is in `Base=
Aspect::runInferior`. That could probably be handled via the CRTP.<br><br>I=
 admit however that I haven&#39;t thought particularly deeply about the pro=
blem.<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/083e2176-c037-4171-abb4-8b46d016a28c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/083e2176-c037-4171-abb4-8b46d016a28c=
%40isocpp.org</a>.<br />

------=_Part_1175_1331672094.1463683443655--

------=_Part_1174_1540360110.1463683443655--

.

------=_Part_344_957526655.1464000573865
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The "sad" thing about pure virtual destructors is that their implementation=
 is generated in the derived class for you if you don't provide it. So the =
primary reason for a function to be pure, forcing the user to provide an ow=
n implementation, vanishes for destructors. The other reason for having pur=
e virtuals remains. You cannot instantiate objects of such classes.
And of course pure virtual destructors are the only pure functions that hav=
e to have a body. Otherwise you can not even derrive from that class.

--=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/f16a45ea-e055-4bba-b726-0289e7c64c8e%40isocpp.or=
g.

------=_Part_344_957526655.1464000573865--

.

------=_Part_296_1650617182.1464001158775
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The "sad" thing about pure virtual destructors is that their implementation=
 is generated in the derived class for you if you don't provide it. So the =
primary reason for a function to be pure, forcing the user to provide an ow=
n implementation, vanishes for destructors. The other reason for having pur=
e virtuals remains. You cannot instantiate objects of such classes.
And of course pure virtual destructors are the only pure functions that hav=
e to have a body. Otherwise you can not even derrive from that class.

--=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/6676b5a1-2762-4279-8671-0d46251b8c08%40isocpp.or=
g.

------=_Part_296_1650617182.1464001158775--

.