Topic: Allow "explicit" as a modifier for reference and
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 27 Feb 2016 13:36:55 -0800 (PST)
Raw View
------=_Part_400_1726022206.1456609015046
Content-Type: multipart/alternative;
boundary="----=_Part_401_1847043794.1456609015046"
------=_Part_401_1847043794.1456609015046
Content-Type: text/plain; charset=UTF-8
This would block implicit conversion of a derived class reference/pointer
to a base class reference/pointer. One use would be to prevent the
unexpected use of a comparison operator of a base class for an instance of
a derived class.
--
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/078d9bdc-ac73-4443-93d5-b11a26dc34ae%40isocpp.org.
------=_Part_401_1847043794.1456609015046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This would block implicit conversion of a derived class re=
ference/pointer to a base class reference/pointer.=C2=A0 One use would be t=
o prevent the unexpected use of a comparison operator of a base class for a=
n instance of a derived class.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/078d9bdc-ac73-4443-93d5-b11a26dc34ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/078d9bdc-ac73-4443-93d5-b11a26dc34ae=
%40isocpp.org</a>.<br />
------=_Part_401_1847043794.1456609015046--
------=_Part_400_1726022206.1456609015046--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 27 Feb 2016 15:28:12 -0800
Raw View
On s=C3=A1bado, 27 de fevereiro de 2016 13:36:55 PST 'Walt Karas' via ISO C=
++=20
Standard - Future Proposals wrote:
> This would block implicit conversion of a derived class reference/pointer
> to a base class reference/pointer. One use would be to prevent the
> unexpected use of a comparison operator of a base class for an instance o=
f
> a derived class.
Polymorphic classes don't usually have comparison operators.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/5041843.gxK7cZtefI%40tjmaciei-mobl4.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 29 Feb 2016 20:45:05 -0800 (PST)
Raw View
------=_Part_4175_1015611799.1456807505559
Content-Type: multipart/alternative;
boundary="----=_Part_4176_1480010334.1456807505559"
------=_Part_4176_1480010334.1456807505559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, February 27, 2016 at 6:28:17 PM UTC-5, Thiago Macieira wrote:
>
> On s=C3=A1bado, 27 de fevereiro de 2016 13:36:55 PST 'Walt Karas' via ISO=
C++=20
> Standard - Future Proposals wrote:=20
> > This would block implicit conversion of a derived class=20
> reference/pointer=20
> > to a base class reference/pointer. One use would be to prevent the=20
> > unexpected use of a comparison operator of a base class for an instance=
=20
> of=20
> > a derived class.=20
>
> Polymorphic classes don't usually have comparison operators.
>
Equally importantly, I'm not sure why you would *want* to prevent such a=20
use of a comparison operator if you provided one. The whole point of=20
polymorphism is that you can treat the derived class as though it were the=
=20
base class. So if your base class interface includes operator overloading,=
=20
your derived class interface should behave in the same way. So it should be=
=20
perfectly valid to compare a `Derived&` with a `Base&`, and to do so using=
=20
the `operator<(Base&, Base&)` function by default.
If you find that problematic, odds are good that you're abusing=20
polymorphism somewhere.
--=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/bbd78ae1-6e7d-46ae-9e58-b4a760a51d09%40isocpp.or=
g.
------=_Part_4176_1480010334.1456807505559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, February 27, 2016 at 6:28:17 PM UTC-5=
, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=
=C3=A1bado, 27 de fevereiro de 2016 13:36:55 PST 'Walt Karas' via I=
SO C++=20
<br>Standard - Future Proposals wrote:
<br>> This would block implicit conversion of a derived class reference/=
pointer
<br>> to a base class reference/pointer. =C2=A0One use would be to preve=
nt the
<br>> unexpected use of a comparison operator of a base class for an ins=
tance of
<br>> a derived class.
<br>
<br>Polymorphic classes don't usually have comparison operators.<br></b=
lockquote><div><br>Equally importantly, I'm not sure why you would <i>w=
ant</i> to prevent such a use of a comparison operator if you provided one.=
The whole point of polymorphism is that you can treat the derived class as=
though it were the base class. So if your base class interface includes op=
erator overloading, your derived class interface should behave in the same =
way. So it should be perfectly valid to compare a `Derived&` with a `Ba=
se&`, and to do so using the `operator<(Base&, Base&)` funct=
ion by default.<br><br>If you find that problematic, odds are good that you=
're abusing polymorphism somewhere.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/bbd78ae1-6e7d-46ae-9e58-b4a760a51d09%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bbd78ae1-6e7d-46ae-9e58-b4a760a51d09=
%40isocpp.org</a>.<br />
------=_Part_4176_1480010334.1456807505559--
------=_Part_4175_1015611799.1456807505559--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 29 Feb 2016 23:53:15 -0500
Raw View
--001a113f87606d2b6e052cf58d5c
Content-Type: text/plain; charset=UTF-8
On 29 February 2016 at 23:45, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Saturday, February 27, 2016 at 6:28:17 PM UTC-5, Thiago Macieira wrote:
>>
>> Polymorphic classes don't usually have comparison operators.
>>
>
> Equally importantly, I'm not sure why you would *want* to prevent such a
> use of a comparison operator if you provided one. The whole point of
> polymorphism is that you can treat the derived class as though it were the
> base class. So if your base class interface includes operator overloading,
> your derived class interface should behave in the same way. So it should be
> perfectly valid to compare a `Derived&` with a `Base&`, and to do so using
> the `operator<(Base&, Base&)` function by default.
>
> If you find that problematic, odds are good that you're abusing
> polymorphism somewhere.
>
You may wish to contact the author of n4475
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf> and let
him know your differing views on the subject, especially before it gets
standardized.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BPq4vcvoMrX3Dm63Aus4%2Bw1MqRruz9PpHD7O5sF3ZQRhg%40mail.gmail.com.
--001a113f87606d2b6e052cf58d5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 29 February 2016 at 23:45, Nicol Bolas <span dir=3D"ltr=
"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
"><br><br>On Saturday, February 27, 2016 at 6:28:17 PM UTC-5, Thiago Maciei=
ra wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">Polymorphic classes don=
9;t usually have comparison operators.<br></blockquote></span><div><br>Equa=
lly importantly, I'm not sure why you would <i>want</i> to prevent such=
a use of a comparison operator if you provided one. The whole point of pol=
ymorphism is that you can treat the derived class as though it were the bas=
e class. So if your base class interface includes operator overloading, you=
r derived class interface should behave in the same way. So it should be pe=
rfectly valid to compare a `Derived&` with a `Base&`, and to do so =
using the `operator<(Base&, Base&)` function by default.<br><br>=
If you find that problematic, odds are good that you're abusing polymor=
phism somewhere.<br></div></div></blockquote><div><br></div><div>You may wi=
sh to contact the author of <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/n4475.pdf">n4475</a> and let him know your differing vi=
ews on the subject, especially before it gets standardized.</div></div>-- <=
br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><d=
iv>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nev=
in@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=
=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BPq4vcvoMrX3Dm63Aus4%2Bw1MqRr=
uz9PpHD7O5sF3ZQRhg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPq4v=
cvoMrX3Dm63Aus4%2Bw1MqRruz9PpHD7O5sF3ZQRhg%40mail.gmail.com</a>.<br />
--001a113f87606d2b6e052cf58d5c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 29 Feb 2016 21:20:02 -0800 (PST)
Raw View
------=_Part_4256_1140865891.1456809602605
Content-Type: multipart/alternative;
boundary="----=_Part_4257_1101880437.1456809602606"
------=_Part_4257_1101880437.1456809602606
Content-Type: text/plain; charset=UTF-8
On Monday, February 29, 2016 at 11:53:56 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 29 February 2016 at 23:45, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>>
>>
>> On Saturday, February 27, 2016 at 6:28:17 PM UTC-5, Thiago Macieira wrote:
>>>
>>> Polymorphic classes don't usually have comparison operators.
>>>
>>
>> Equally importantly, I'm not sure why you would *want* to prevent such a
>> use of a comparison operator if you provided one. The whole point of
>> polymorphism is that you can treat the derived class as though it were the
>> base class. So if your base class interface includes operator overloading,
>> your derived class interface should behave in the same way. So it should be
>> perfectly valid to compare a `Derived&` with a `Base&`, and to do so using
>> the `operator<(Base&, Base&)` function by default.
>>
>> If you find that problematic, odds are good that you're abusing
>> polymorphism somewhere.
>>
>
> You may wish to contact the author of n4475
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf> and
> let him know your differing views on the subject, especially before it gets
> standardized.
>
>
Nothing in that paper conflicts with what I said.
Section 2.15 of that paper says: "If a class has a virtual function
(directly or inherited), no == is generated." The OP is clearly talking
about a polymorphic type, so that line applies: no `operator==` is
generated. Therefore, the user must have provided such a function, in which
case the usual rules for operator overloading apply.
What you're thinking about is probably the rest of 2.15, where it says that
`b==a` doesn't work for the generated operator==. But note that the paper
is very careful not to outlaw existing behavior. If you provide an
`operator==` for the base class, `b==a` will still work, using the regular
rules of C++. That is, 2.15 only outlaws it for *generated* operators.
Indeed, the entire paper goes through great pains to say that generated
operators are not normal functions and do not partake in function
overloading like regular functions.
--
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/c9581548-936a-41a0-846f-391ac133cd5c%40isocpp.org.
------=_Part_4257_1101880437.1456809602606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 29, 2016 at 11:53:56 PM UTC-5,=
Nevin ":-)" Liber 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">On 29 February 2016 at 23:45, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"V2XZnFwEBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Sa=
turday, February 27, 2016 at 6:28:17 PM UTC-5, Thiago Macieira wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">Polymorphic classes don't usually hav=
e comparison operators.<br></blockquote></span><div><br>Equally importantly=
, I'm not sure why you would <i>want</i> to prevent such a use of a com=
parison operator if you provided one. The whole point of polymorphism is th=
at you can treat the derived class as though it were the base class. So if =
your base class interface includes operator overloading, your derived class=
interface should behave in the same way. So it should be perfectly valid t=
o compare a `Derived&` with a `Base&`, and to do so using the `oper=
ator<(Base&, Base&)` function by default.<br><br>If you find tha=
t problematic, odds are good that you're abusing polymorphism somewhere=
..<br></div></div></blockquote><div><br></div><div>You may wish to contact t=
he author of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2015/n4475.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4475.pdf\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEN9hkR1Mx1bwyYCBd44bXPtlD6Aw';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4475.pdf\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEN9hkR1Mx1bwyYCBd44bXPtlD6Aw';return true;">n4475</a> and le=
t him know your differing views on the subject, especially before it gets s=
tandardized.</div></div><br></div></div></blockquote><div><br>Nothing in th=
at paper conflicts with what I said.<br><br>Section 2.15 of that paper says=
: "If a class has a virtual function (directly or inherited), no =3D=
=3D is generated." The OP is clearly talking about a polymorphic type,=
so that line applies: no `operator=3D=3D` is generated. Therefore, the use=
r must have provided such a function, in which case the usual rules for ope=
rator overloading apply.<br><br>What you're thinking about is probably =
the rest of 2.15, where it says that `b=3D=3Da` doesn't work for the ge=
nerated operator=3D=3D. But note that the paper is very careful not to outl=
aw existing behavior. If you provide an `operator=3D=3D` for the base class=
, `b=3D=3Da` will still work, using the regular rules of C++. That is, 2.15=
only outlaws it for <i>generated</i> operators.<br><br>Indeed, the entire =
paper goes through great pains to say that generated operators are not norm=
al functions and do not partake in function overloading like regular functi=
ons.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c9581548-936a-41a0-846f-391ac133cd5c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c9581548-936a-41a0-846f-391ac133cd5c=
%40isocpp.org</a>.<br />
------=_Part_4257_1101880437.1456809602606--
------=_Part_4256_1140865891.1456809602605--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 1 Mar 2016 00:27:16 -0500
Raw View
--001a11396de8128d6f052cf60741
Content-Type: text/plain; charset=UTF-8
On 1 March 2016 at 00:20, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Nothing in that paper conflicts with what I said.
>
Really? How about the other part of 2.15:
"Writing a good == for a class hierarchy is in general difficult and
typically involves one or more virtual functions. For extra complications,
compare objects of two different classes D1 and D2 derived from a common
base B with a ==."
And yet you say:
The whole point of polymorphism is that you can treat the derived class as
> though it were the base class. So if your base class interface includes
> operator overloading, your derived class interface should behave in the
> same way. So it should be perfectly valid to compare a `Derived&` with a
> `Base&`, and to do so using the `operator<(Base&, Base&)` function by
> default.
>
> If you find that problematic, odds are good that you're abusing
> polymorphism somewhere.
So, is it "in general difficult" or "abusing polymorphism" to provide a
correct implementation of operator== for a base class? It cannot be both.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BON8eVB0Ub8ExXyX1-UgsCCGxUXUZZVMumvT_u30MCMzA%40mail.gmail.com.
--001a11396de8128d6f052cf60741
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 1 March 2016 at 00:20, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex"><div dir=3D"ltr"><br>Nothing in that paper conflic=
ts with what I said.<br></div></blockquote><div><br></div><div>Really?=C2=
=A0 How about the other part of 2.15:</div><div><br></div><div>"<span =
style=3D"font-size:11pt;font-family:Calibri">Writing a good </span><span st=
yle=3D"font-size:11pt;font-family:Calibri;font-weight:700">=3D=3D </span><s=
pan style=3D"font-size:11pt;font-family:Calibri">for a class hierarchy is i=
n general difficult and typically
involves one or more virtual functions. For extra complications, compare ob=
jects of two different classes
</span><span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">D=
1 </span><span style=3D"font-size:11pt;font-family:Calibri">and </span><spa=
n style=3D"font-size:11pt;font-family:Calibri;font-weight:700">D2 </span><s=
pan style=3D"font-size:11pt;font-family:Calibri">derived from a common base=
</span><span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">=
B </span><span style=3D"font-size:11pt;font-family:Calibri">with a </span><=
span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">=3D=3D</s=
pan><span style=3D"font-size:11pt;font-family:Calibri">."</span></div>=
<div><br></div><div>And yet you say:</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
The whole point of polymorphism is that you can treat the derived class as =
though it were the base class. So if your base class interface includes ope=
rator overloading, your derived class interface should behave in the same w=
ay. So it should be perfectly valid to compare a `Derived&` with a `Bas=
e&`, and to do so using the `operator<(Base&, Base&)` functi=
on by default.<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If you fin=
d that problematic, odds are good that you're abusing polymorphism some=
where.</blockquote><div><br></div><div>So, is it "in general difficult=
" or "abusing polymorphism" to provide a correct implementat=
ion of operator=3D=3D for a base class?=C2=A0 It cannot be both.</div><div>=
--=C2=A0<br></div></div><div class=3D"gmail_signature"><div dir=3D"ltr"><di=
v><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:=
<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverl=
ord.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BON8eVB0Ub8ExXyX1-UgsCCGxUXUZ=
ZVMumvT_u30MCMzA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BON8eVB=
0Ub8ExXyX1-UgsCCGxUXUZZVMumvT_u30MCMzA%40mail.gmail.com</a>.<br />
--001a11396de8128d6f052cf60741--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 1 Mar 2016 06:46:56 -0800 (PST)
Raw View
------=_Part_4764_1643630998.1456843616887
Content-Type: multipart/alternative;
boundary="----=_Part_4765_1835097501.1456843616888"
------=_Part_4765_1835097501.1456843616888
Content-Type: text/plain; charset=UTF-8
On Tuesday, March 1, 2016 at 12:27:57 AM UTC-5, Nevin ":-)" Liber wrote:
>
> On 1 March 2016 at 00:20, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>>
>> Nothing in that paper conflicts with what I said.
>>
>
> Really? How about the other part of 2.15:
>
> "Writing a good == for a class hierarchy is in general difficult and
> typically involves one or more virtual functions. For extra complications,
> compare objects of two different classes D1 and D2 derived from a common
> base B with a ==."
>
> And yet you say:
>
> The whole point of polymorphism is that you can treat the derived class as
>> though it were the base class. So if your base class interface includes
>> operator overloading, your derived class interface should behave in the
>> same way. So it should be perfectly valid to compare a `Derived&` with a
>> `Base&`, and to do so using the `operator<(Base&, Base&)` function by
>> default.
>>
>
>
>> If you find that problematic, odds are good that you're abusing
>> polymorphism somewhere.
>
>
> So, is it "in general difficult" or "abusing polymorphism" to provide a
> correct implementation of operator== for a base class? It cannot be both.
>
Allow me to clarify my last sentence, with underlining to show the changed
text:
If you find that *allowing `operator<(const Base&, const Base&)` to be
> called on `Derived` instances to be* problematic, odds are good that
> you're abusing polymorphism somewhere.
>
It's not having `operator<` for base classes that's abusing polymorphism.
It's wanting to explicitly *deny* that operator's use on derived classes
that suggests an abuse of polymorphism. And such denial is apparently one
of the motivations for this 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/79ea25eb-42cd-4227-84dd-d2738dc70e91%40isocpp.org.
------=_Part_4765_1835097501.1456843616888
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 1, 2016 at 12:27:57 AM UTC-5, Nevin &quo=
t;:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On 1 March 2016 at 00:20, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TxeR5jcGBAAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@g=
mail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br>Nothing in that paper conflicts with what I sa=
id.<br></div></blockquote><div><br></div><div>Really?=C2=A0 How about the o=
ther part of 2.15:</div><div><br></div><div>"<span style=3D"font-size:=
11pt;font-family:Calibri">Writing a good </span><span style=3D"font-size:11=
pt;font-family:Calibri;font-weight:700">=3D=3D </span><span style=3D"font-s=
ize:11pt;font-family:Calibri">for a class hierarchy is in general difficult=
and typically
involves one or more virtual functions. For extra complications, compare ob=
jects of two different classes
</span><span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">D=
1 </span><span style=3D"font-size:11pt;font-family:Calibri">and </span><spa=
n style=3D"font-size:11pt;font-family:Calibri;font-weight:700">D2 </span><s=
pan style=3D"font-size:11pt;font-family:Calibri">derived from a common base=
</span><span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">=
B </span><span style=3D"font-size:11pt;font-family:Calibri">with a </span><=
span style=3D"font-size:11pt;font-family:Calibri;font-weight:700">=3D=3D</s=
pan><span style=3D"font-size:11pt;font-family:Calibri">."</span></div>=
<div><br></div><div>And yet you say:</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
The whole point of polymorphism is that you can treat the derived class as =
though it were the base class. So if your base class interface includes ope=
rator overloading, your derived class interface should behave in the same w=
ay. So it should be perfectly valid to compare a `Derived&` with a `Bas=
e&`, and to do so using the `operator<(Base&, Base&)` functi=
on by default.<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If you fin=
d that problematic, odds are good that you're abusing polymorphism some=
where.</blockquote><div><br></div><div>So, is it "in general difficult=
" or "abusing polymorphism" to provide a correct implementat=
ion of operator=3D=3D for a base class?=C2=A0 It cannot be both.</div></div=
></div></div></blockquote><div><br>Allow me to clarify my last sentence, wi=
th underlining to show the changed text:<br><br><blockquote style=3D"margin=
: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;" class=3D"gmail_quote">If you find that <u>allowing `operator<(c=
onst Base&, const Base&)` to be called on `Derived` instances to be=
</u> problematic, odds are good that you're abusing polymorphism somewh=
ere.<br></blockquote><br>It's not having `operator<` for base classe=
s that's abusing polymorphism. It's wanting to explicitly <i>deny</=
i> that operator's use on derived classes that suggests an abuse of pol=
ymorphism. And such denial is apparently one of the motivations for this id=
ea.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/79ea25eb-42cd-4227-84dd-d2738dc70e91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79ea25eb-42cd-4227-84dd-d2738dc70e91=
%40isocpp.org</a>.<br />
------=_Part_4765_1835097501.1456843616888--
------=_Part_4764_1643630998.1456843616887--
.