Topic: Proposal to turn non-member function templates
Author: David Krauss <potswa@gmail.com>
Date: Thu, 8 Oct 2015 22:22:48 +0800
Raw View
--Apple-Mail=_9F156F9D-C302-4A3F-80E9-D2BACCD12000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9308, at 9:53 PM, Lingxi Li <lilingxi.cs@gmail.c=
om> wrote:
>=20
> To remedy this issue, I propose to define the non-member functions inline=
as friends of their corresponding class template.=20
If changing the existing library is too much, could we at least change the =
policy going forward? Fundamentals v1 and the various variant proposals all=
have relational operator templates. Besides not supporting conversions, th=
ey pollute the overload set (and error messages) when ADL or using namespac=
e brings in std.
This little snippet gives me about a page of errors:
#include <vector>
#include <deque>
#include <string>
bool l =3D std::string("hi") < 5;
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_9F156F9D-C302-4A3F-80E9-D2BACCD12000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9308, at 9:53 PM, Lingxi Li <<a href=3D"mailto:lilingxi.cs@gmail.=
com" class=3D"">lilingxi.cs@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><font face=3D"Arial, sans-serif" sty=
le=3D"font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D=
""><span style=3D"font-size: 13.3333px;" class=3D"">To remedy this issue, I=
propose to d</span></font><font face=3D"Arial, sans-serif" style=3D"font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; font-size: 13.3333px;" class=3D"">efin=
e the non-member functions inline as friends of their corresponding class t=
emplate.<span class=3D"Apple-converted-space"> </span></font></div></b=
lockquote></div><br class=3D""><div class=3D"">If changing the existing lib=
rary is too much, could we at least change the policy going forward? Fundam=
entals v1 and the various variant proposals all have relational operator te=
mplates. Besides not supporting conversions, they pollute the overload set =
(and error messages) when ADL or <font face=3D"Courier" class=3D"">using na=
mespace</font> brings in <font face=3D"Courier" class=3D"">std</font>.</div=
><div class=3D""><br class=3D""></div><div class=3D"">This little snippet g=
ives me about a page of errors:</div><div class=3D""><br class=3D""></div><=
div class=3D""><font face=3D"Courier" class=3D"">#include <vector><br=
class=3D"">#include <deque><br class=3D"">#include <string><br=
class=3D""><br class=3D"">bool l =3D std::string("hi") < 5;<br class=3D=
""></font><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_9F156F9D-C302-4A3F-80E9-D2BACCD12000--
.
Author: Lingxi Li <lilingxi.cs@gmail.com>
Date: Thu, 8 Oct 2015 08:25:38 -0700 (PDT)
Raw View
------=_Part_70_1147428041.1444317938314
Content-Type: multipart/alternative;
boundary="----=_Part_71_527685973.1444317938314"
------=_Part_71_527685973.1444317938314
Content-Type: text/plain; charset=UTF-8
On Thursday, October 8, 2015 at 10:23:04 PM UTC+8, David Krauss wrote:
>
>
> If changing the existing library is too much, could we at least change the
> policy going forward? Fundamentals v1 and the various variant proposals all
> have relational operator templates. Besides not supporting conversions,
> they pollute the overload set (and error messages) when ADL or using
> namespace brings in std.
>
> This little snippet gives me about a page of errors:
>
> #include <vector>
> #include <deque>
> #include <string>
>
> bool l = std::string("hi") < 5;
>
>
I get your point regarding polluting the overload set. The proposed design
change helps solving it also. With respect to the *policy* you mentioned,
could you say something more about it? I do not quite get your idea.
It is undeniable that the proposed fix requires a careful review of the
whole library, modifying little things scattered in many different places.
Still, I cannot think of a better way to solve the issue. If no better
solution comes out, the proposed fix, though requiring tedious refactoring
work, should worth the effort. It is the standard library after all.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_71_527685973.1444317938314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>On Thursday, October 8, 2015 at 10:23:04 PM=
UTC+8, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v style=3D"word-wrap:break-word"><br><div>If changing the existing library =
is too much, could we at least change the policy going forward? Fundamental=
s v1 and the various variant proposals all have relational operator templat=
es. Besides not supporting conversions, they pollute the overload set (and =
error messages) when ADL or <font face=3D"Courier">using namespace</font> b=
rings in <font face=3D"Courier">std</font>.</div><div><br></div><div>This l=
ittle snippet gives me about a page of errors:</div><div><br></div><div><fo=
nt face=3D"Courier">#include <vector><br>#include <deque><br>#i=
nclude <string><br><br>bool l =3D std::string("hi") < 5;=
<br></font><br></div></div></blockquote><div><br></div><div>I get your poin=
t regarding polluting the overload set. The proposed design change helps so=
lving it also. With respect to the <i>policy</i> you mentioned, could you s=
ay something more about it? I do not quite get your idea. =C2=A0</div><div>=
It is undeniable that the proposed fix requires a careful review of the who=
le library, modifying little things scattered in many different places. Sti=
ll, I cannot think of a better way to solve the issue. If no better solutio=
n comes out, the proposed fix, though requiring tedious refactoring work, s=
hould worth the effort. It is the standard library after all.</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_71_527685973.1444317938314--
------=_Part_70_1147428041.1444317938314--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 9 Oct 2015 09:33:02 +0800
Raw View
--Apple-Mail=_D034A7BB-8427-4E3C-9A64-7A5D96F2C126
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9310=E2=80=9308, at 11:25 PM, Lingxi Li <lilingxi.cs@gmail.=
com> wrote:
>=20
> I get your point regarding polluting the overload set. The proposed desig=
n change helps solving it also. With respect to the policy you mentioned, c=
ould you say something more about it? I do not quite get your idea. =20
I mean, if changing all the current standard classes would be too drastic, =
perhaps the growth of the problem could be stemmed by using friend operator=
overloads in future standardization.
There could still be a good reason behind non-friend templates, I don=E2=80=
=99t know. Hope anyone would chime in if they do. Historically, friend non-=
templates were tricky to implement. Without invisibility, they lead to even=
worse overload set pollution. SGI STL may well have predated them complete=
ly.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_D034A7BB-8427-4E3C-9A64-7A5D96F2C126
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9308, at 11:25 PM, Lingxi Li <<a href=3D"mailto:lilingxi.cs@gmail=
..com" class=3D"">lilingxi.cs@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><div style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">=
I get your point regarding polluting the overload set. The proposed design =
change helps solving it also. With respect to the<span class=3D"Apple-conve=
rted-space"> </span><i class=3D"">policy</i><span class=3D"Apple-conve=
rted-space"> </span>you mentioned, could you say something more about =
it? I do not quite get your idea. </div></div></blockquote></div><br =
class=3D""><div class=3D"">I mean, if changing all the current standard cla=
sses would be too drastic, perhaps the growth of the problem could be stemm=
ed by using friend operator overloads in future standardization.</div><div =
class=3D""><br class=3D""></div><div class=3D"">There could still be a good=
reason behind non-friend templates, I don=E2=80=99t know. Hope anyone woul=
d chime in if they do. Historically, friend non-templates were tricky to im=
plement. Without invisibility, they lead to even worse overload set polluti=
on. SGI STL may well have predated them completely.</div><div class=3D""><b=
r class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_D034A7BB-8427-4E3C-9A64-7A5D96F2C126--
.