Topic: Removing forward references ("universal
Author: Brian Bi <bbi5291@gmail.com>
Date: Sun, 26 Feb 2017 00:13:11 -0800
Raw View
--001a1144ca22b1ba1b05496a8800
Content-Type: text/plain; charset=UTF-8
On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <redradist@gmail.com> wrote:
> Hi All,
>
> My proposal is very simple. Just remove completely forward references
> because of confusion that it makes until it is not too late !!
>
Sorry, you're about six years too late.
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know
>
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single responsibility).
> I should use one function only for *rvalue *references or for *lvalue *references.
> Mixing together handling of both references is bad practice.
>
> What do you think ?
>
> --
> 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/f4a47328-5397-4e93-
> 9453-ddb978256627%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-5397-4e93-9453-ddb978256627%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
*Brian Bi*
--
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/CAMmfjbMSL3z1U_ektHTrY2mMrphnOc%2B2K04WM5gu2FiiZxiyJw%40mail.gmail.com.
--001a1144ca22b1ba1b05496a8800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <span dir=3D"ltr"><<a =
href=3D"mailto:redradist@gmail.com" target=3D"_blank">redradist@gmail.com</=
a>></span> wrote:<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"><di=
v>Hi All,</div><div><br></div><div>My proposal is very simple. Just remove =
completely=C2=A0forward references because of confusion that it makes until=
it is not too late !!</div></div></blockquote><div><br></div><div>Sorry, y=
ou're about six years too late.<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Basically if we have the following =
example:</div><div><br></div><div>=C2=A0 =C2=A0 template<typename T><=
/div><div>=C2=A0 =C2=A0 void setItem(T && t)</div><div>=C2=A0 =C2=
=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rvalue </b>reference as all of y=
ou know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 }</div><div><br=
></div><div>But it confuses ( I think ) all of us.</div><div>Actually it ev=
en violates <b>SOLID </b>principale (S - Single responsibility). I should u=
se one function only for <b>rvalue </b>references or for <b>lvalue </b>refe=
rences. Mixing together handling of both references is bad practice.</div><=
div><br></div><div>What do you think ?</div></div><span class=3D"HOEnZb"><f=
ont color=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4a47328-5397-4e93-9453-ddb978256627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f4a4=
7328-5397-4e93-<wbr>9453-ddb978256627%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div=
></div><div></div><div></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/CAMmfjbMSL3z1U_ektHTrY2mMrphnOc%2B2K0=
4WM5gu2FiiZxiyJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMSL3z1U_=
ektHTrY2mMrphnOc%2B2K04WM5gu2FiiZxiyJw%40mail.gmail.com</a>.<br />
--001a1144ca22b1ba1b05496a8800--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 26 Feb 2017 00:50:43 -0800 (PST)
Raw View
------=_Part_561_423014202.1488099043926
Content-Type: multipart/alternative;
boundary="----=_Part_562_451376287.1488099043926"
------=_Part_562_451376287.1488099043926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I do not think so.
Never is late !!
If something was done wrong -> we have to admit it.
*If somebody say:** "We cannot throw out it for backward compatibility"*, *=
I=20
will say:* *"Backward compatibility for bug-prone code is insane".*
It is like a bad habit. If we put up with it and in future may be will make=
=20
the same mistakes then it is not an evolution, but degradation and=20
producing more bug-prone code.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 10:13:15 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Brian Bi=
=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <redr...@gmail.com=20
> <javascript:>> wrote:
>
>> Hi All,
>>
>> My proposal is very simple. Just remove completely forward references=20
>> because of confusion that it makes until it is not too late !!
>>
>
> Sorry, you're about six years too late.
> =20
>
>> Basically if we have the following example:
>>
>> template<typename T>
>> void setItem(T && t)
>> {
>> ...
>> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
>> =20
>> }
>>
>> But it confuses ( I think ) all of us.
>> Actually it even violates *SOLID *principale (S - Single=20
>> responsibility). I should use one function only for *rvalue *references=
=20
>> or for *lvalue *references. Mixing together handling of both references=
=20
>> is bad practice.
>>
>> What do you think ?
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-53=
97-4e93-9453-ddb978256627%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-5=
397-4e93-9453-ddb978256627%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --=20
> *Brian Bi*
>
--=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/1cb5f6b6-2488-4c75-a606-41c916fcf94f%40isocpp.or=
g.
------=_Part_562_451376287.1488099043926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I do not think so.</div><div>Never is late !!</d=
iv><div><br></div><div>If something was done wrong -> we have to admit i=
t.</div><div><b>If somebody say:</b><i> "We cannot throw out it for ba=
ckward compatibility"</i>, <b>I will say:</b> <i>"Backward compat=
ibility for bug-prone code is insane".</i></div><div>It is like a bad =
habit. If we put up with it and in future may be will make the same mistake=
s then it is not an evolution, but degradation and producing more bug-prone=
code.</div><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 26 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 10:1=
3:15 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Brian Bi =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D=
"gmail_quote">On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <span dir=3D"lt=
r"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A=
HdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">redr...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>Hi All,</div><div><br></div><div>My proposal is very=
simple. Just remove completely=C2=A0forward references because of confusio=
n that it makes until it is not too late !!</div></div></blockquote><div><b=
r></div><div>Sorry, you're about six years too late.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Basically if =
we have the following example:</div><div><br></div><div>=C2=A0 =C2=A0 templ=
ate<typename T></div><div>=C2=A0 =C2=A0 void setItem(T && t)<=
/div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rvalue </b>r=
eference as all of you know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =
=C2=A0 }</div><div><br></div><div>But it confuses ( I think ) all of us.</d=
iv><div>Actually it even violates <b>SOLID </b>principale (S - Single respo=
nsibility). I should use one function only for <b>rvalue </b>references or =
for <b>lvalue </b>references. Mixing together handling of both references i=
s bad practice.</div><div><br></div><div>What do you think ?</div></div><sp=
an><font color=3D"#888888">
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
AHdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"AHdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/f4a47328-5397-4e93-9453-ddb978256627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f4a47328-5397-4e93-9453-ddb978256627%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/f4a47328-5397-4e93-9453-ddb978256627%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f4a47328-5397-4e93-<wbr>9453-=
ddb978256627%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i><=
/font><br><div></div><div></div><div></div></div></div></div></div>
</div></div>
</blockquote></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/1cb5f6b6-2488-4c75-a606-41c916fcf94f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cb5f6b6-2488-4c75-a606-41c916fcf94f=
%40isocpp.org</a>.<br />
------=_Part_562_451376287.1488099043926--
------=_Part_561_423014202.1488099043926--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Sun, 26 Feb 2017 03:05:45 -0600
Raw View
On Sun, Feb 26, 2017 at 2:50 AM, Denis Kotov <redradist@gmail.com> wrote:
> If somebody say: "We cannot throw out it for backward compatibility", I will
> say: "Backward compatibility for bug-prone code is insane".
I'm as insane as any Python 2 users.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuApHxzeAqks0cnoybayARQdXc2tO%2BP2XMrCnTXJiNgBig%40mail.gmail.com.
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 26 Feb 2017 01:16:11 -0800 (PST)
Raw View
------=_Part_586_1538198231.1488100571120
Content-Type: multipart/alternative;
boundary="----=_Part_587_1876010545.1488100571120"
------=_Part_587_1876010545.1488100571120
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Oh come on,
*Python 2* was in some places very bug-prone. Consider the *Python 2*=20
searching attribute in tree of parents (*DFS - Depth-First Search*). In=20
Python 3 more better search (*BFS - **Breadth-First Search*), more=20
predictable.
But anyway, we are taking about C++. And untill using "universal reference"=
=20
grown up to much we need remove this stuff from the standard !!
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 11:05:48 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Zhihao Y=
uan=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Sun, Feb 26, 2017 at 2:50 AM, Denis Kotov <redr...@gmail.com=20
> <javascript:>> wrote:=20
> > If somebody say: "We cannot throw out it for backward compatibility", I=
=20
> will=20
> > say: "Backward compatibility for bug-prone code is insane".=20
>
> I'm as insane as any Python 2 users.=20
>
> --=20
> Zhihao Yuan, ID lichray=20
> The best way to predict the future is to invent it.=20
> ___________________________________________________=20
> 4BSD -- http://blog.miator.net/=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c89707f6-36a5-47b7-bbda-41706fbb528c%40isocpp.or=
g.
------=_Part_587_1876010545.1488100571120
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Oh come on,</div><div><br></div><div><b>Python 2</b> =
was in some places very bug-prone. Consider the <b>Python 2</b> searching a=
ttribute in tree of parents (<b>DFS - Depth-First Search</b>). In Python 3 =
more better search (<b>BFS -=C2=A0</b><b>Breadth-First Search</b>), more pr=
edictable.</div><div><br></div><div>But anyway, we are taking about C++. An=
d untill using "universal reference" grown up to much we need rem=
ove this stuff from the standard !!</div><div><br>=D0=B2=D0=BE=D1=81=D0=BA=
=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=84=D0=B5=D0=B2=D1=80=D0=
=B0=D0=BB=D1=8F 2017 =D0=B3., 11:05:48 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Zhihao Yuan =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Su=
n, Feb 26, 2017 at 2:50 AM, Denis Kotov <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"dE6VzKKUAgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">redr...@gmail.com</a>> wrote:
<br>> If somebody say: "We cannot throw out it for backward compati=
bility", I will
<br>> say: "Backward compatibility for bug-prone code is insane&quo=
t;.
<br>
<br>I'm as insane as any Python 2 users.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmWTsHV=
Z1D7s1tahvZikRjgaSh7g';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHmWTsHVZ1D7s1tahvZikRjgaSh7g';return true;">http:=
//blog.miator.net/</a>
<br></blockquote></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/c89707f6-36a5-47b7-bbda-41706fbb528c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c89707f6-36a5-47b7-bbda-41706fbb528c=
%40isocpp.org</a>.<br />
------=_Part_587_1876010545.1488100571120--
------=_Part_586_1538198231.1488100571120--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 26 Feb 2017 01:19:05 -0800 (PST)
Raw View
------=_Part_617_495200096.1488100745321
Content-Type: multipart/alternative;
boundary="----=_Part_618_1046114279.1488100745321"
------=_Part_618_1046114279.1488100745321
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
For C++ it is not so long time ago 6 year vs almost 40 years of existence=
=20
the language =3D)))
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 10:13:15 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Brian Bi=
=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <redr...@gmail.com=20
> <javascript:>> wrote:
>
>> Hi All,
>>
>> My proposal is very simple. Just remove completely forward references=20
>> because of confusion that it makes until it is not too late !!
>>
>
> Sorry, you're about six years too late.
> =20
>
>> Basically if we have the following example:
>>
>> template<typename T>
>> void setItem(T && t)
>> {
>> ...
>> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
>> =20
>> }
>>
>> But it confuses ( I think ) all of us.
>> Actually it even violates *SOLID *principale (S - Single=20
>> responsibility). I should use one function only for *rvalue *references=
=20
>> or for *lvalue *references. Mixing together handling of both references=
=20
>> is bad practice.
>>
>> What do you think ?
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-53=
97-4e93-9453-ddb978256627%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-5=
397-4e93-9453-ddb978256627%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --=20
> *Brian Bi*
>
--=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/9108e037-e8fd-4e9c-922e-779fb2c0c632%40isocpp.or=
g.
------=_Part_618_1046114279.1488100745321
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For C++ it is not so long time ago 6 year vs almost 40 yea=
rs of existence the language =3D)))<br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=
=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=
=BB=D1=8F 2017 =D0=B3., 10:13:15 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Brian Bi =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><div><br><div class=3D"gmail_quote">On Sat, Feb 25, 2017 at 11:43 PM=
, Denis Kotov <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"AHdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">redr...@gmail.com</a>></span> wrote:<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>Hi All,</div><div><br><=
/div><div>My proposal is very simple. Just remove completely=C2=A0forward r=
eferences because of confusion that it makes until it is not too late !!</d=
iv></div></blockquote><div><br></div><div>Sorry, you're about six years=
too late.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>Basically if we have the following example:</div><div><br></=
div><div>=C2=A0 =C2=A0 template<typename T></div><div>=C2=A0 =C2=A0 v=
oid setItem(T && t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>=
lvalue </b>or <b>rvalue </b>reference as all of you know =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>But it confus=
es ( I think ) all of us.</div><div>Actually it even violates <b>SOLID </b>=
principale (S - Single responsibility). I should use one function only for =
<b>rvalue </b>references or for <b>lvalue </b>references. Mixing together h=
andling of both references is bad practice.</div><div><br></div><div>What d=
o you think ?</div></div><span><font color=3D"#888888">
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
AHdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"AHdTg8SRAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/f4a47328-5397-4e93-9453-ddb978256627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f4a47328-5397-4e93-9453-ddb978256627%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/f4a47328-5397-4e93-9453-ddb978256627%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f4a47328-5397-4e93-<wbr>9453-=
ddb978256627%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i><=
/font><br><div></div><div></div><div></div></div></div></div></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" 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/9108e037-e8fd-4e9c-922e-779fb2c0c632%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9108e037-e8fd-4e9c-922e-779fb2c0c632=
%40isocpp.org</a>.<br />
------=_Part_618_1046114279.1488100745321--
------=_Part_617_495200096.1488100745321--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Feb 2017 06:49:15 -0800 (PST)
Raw View
------=_Part_4202_729999093.1488120555355
Content-Type: multipart/alternative;
boundary="----=_Part_4203_1319255372.1488120555356"
------=_Part_4203_1319255372.1488120555356
Content-Type: text/plain; charset=UTF-8
On Sunday, February 26, 2017 at 2:43:16 AM UTC-5, Denis Kotov wrote:
>
> Hi All,
>
> My proposal is very simple. Just remove completely forward references
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know
>
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single responsibility).
> I should use one function only for *rvalue *references or for *lvalue *references.
> Mixing together handling of both references is bad practice.
>
> What do you think ?
>
I think it will break every program that uses perfect forwarding. Which is
every program that ever does anything even remotely like:
template<typename ...Args>
void func(Args ...&&args)
{
return func2(std::forward<Args>(args)...);
}
Which means that `make/allocate_shared/unique` are broken. Every `emplace`
function in the standard library is broken. And every such function that
anyone over the last 6+ years has written is broken.
That's a non-starter.
--
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/821ca5fb-66cf-4515-9a11-8d070e51d8f8%40isocpp.org.
------=_Part_4203_1319255372.1488120555356
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, February 26, 2017 at 2:43:16 AM UTC-5, =
Denis Kotov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Hi All,</div><div><br></div><div>My proposal is very simple. Just=
remove completely=C2=A0forward references because of confusion that it mak=
es until it is not too late !!</div><div>Basically if we have the following=
example:</div><div><br></div><div>=C2=A0 =C2=A0 template<typename T>=
</div><div>=C2=A0 =C2=A0 void setItem(T && t)</div><div>=C2=A0 =C2=
=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rvalue </b>reference as all of y=
ou know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 }</div><div><br=
></div><div>But it confuses ( I think ) all of us.</div><div>Actually it ev=
en violates <b>SOLID </b>principale (S - Single responsibility). I should u=
se one function only for <b>rvalue </b>references or for <b>lvalue </b>refe=
rences. Mixing together handling of both references is bad practice.</div><=
div><br></div><div>What do you think ?</div></div></blockquote><div><br>I t=
hink it will break every program that uses perfect forwarding. Which is eve=
ry program that ever does anything even remotely like:<br><br><div style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Args</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">...&&</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> func2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">forw=
ard</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">args</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)...);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">}</span></div></code></div><br>Which m=
eans that `make/allocate_shared/unique` are broken. Every `emplace` functio=
n in the standard library is broken. And every such function that anyone ov=
er the last 6+ years has written is broken.<br><br>That's a non-starter=
..<br><br><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/821ca5fb-66cf-4515-9a11-8d070e51d8f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/821ca5fb-66cf-4515-9a11-8d070e51d8f8=
%40isocpp.org</a>.<br />
------=_Part_4203_1319255372.1488120555356--
------=_Part_4202_729999093.1488120555355--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 26 Feb 2017 16:30:08 +0100
Raw View
This is a multi-part message in MIME format.
--------------7CCE7230ABF6BEB9C6C2F8C3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 26/02/2017 =C3=A0 08:43, Denis Kotov a =C3=A9crit :
> Hi All,
>
> My proposal is very simple. Just remove completely forward references=20
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single=20
> responsibility). I should use one function only for *rvalue=20
> *references or for *lvalue *references. Mixing together handling of=20
> both references is bad practice.
>
> What do you think ?
We need forwarding references, in order to forwarding transparently.
You can propose something different for forwarding references or for=20
rvalue references e.g. &&&. Then you will be able to deprecate something.
Anyway. You couldn't have this before 2020 and the deprecation period=20
would add still 6 years. So you will have the mixture until 2026 in the=20
best case.
You would need to master the current complexity until then ;-)
Vicente
--=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/218337af-618b-4136-e864-615d9b153c1e%40wanadoo.f=
r.
--------------7CCE7230ABF6BEB9C6C2F8C3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 26/02/2017 =C3=A0 08:43, Denis Kotov =
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:f4a47328-5397-4e93-9453-ddb978256627@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>Hi All,</div>
<div><br>
</div>
<div>My proposal is very simple. Just remove completely=C2=A0forwar=
d
references because of confusion that it makes until it is not
too late !!</div>
<div>Basically if we have the following example:</div>
<div><br>
</div>
<div>=C2=A0 =C2=A0 template<typename T></div>
<div>=C2=A0 =C2=A0 void setItem(T && t)</div>
<div>=C2=A0 =C2=A0 {</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rv=
alue </b>reference
as all of you know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div>
<div>=C2=A0 =C2=A0 }</div>
<div><br>
</div>
<div>But it confuses ( I think ) all of us.</div>
<div>Actually it even violates <b>SOLID </b>principale (S -
Single responsibility). I should use one function only for <b>rva=
lue
</b>references or for <b>lvalue </b>references. Mixing
together handling of both references is bad practice.</div>
<div><br>
</div>
<div>What do you think ?</div>
</div>
</blockquote>
<br>
We need forwarding references, in order to forwarding transparently.<br=
>
<br>
You can propose something different for forwarding references or for
rvalue references=C2=A0 e.g. &&&. Then you will be able to
deprecate something.<br>
Anyway. You couldn't have this before 2020 and the deprecation
period would add still 6 years. So you will have the mixture until
2026 in the best case.<br>
<br>
You would need to master the current complexity until then ;-)<br>
<br>
Vicente<br>
</body>
</html>
<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/218337af-618b-4136-e864-615d9b153c1e%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/218337af-618b-4136-e864-615d9b153c1e=
%40wanadoo.fr</a>.<br />
--------------7CCE7230ABF6BEB9C6C2F8C3--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 26 Feb 2017 07:49:31 -0800 (PST)
Raw View
------=_Part_674_992222847.1488124171545
Content-Type: multipart/alternative;
boundary="----=_Part_675_1411237051.1488124171546"
------=_Part_675_1411237051.1488124171546
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
But it is not so difficult ... little bit refactoring, change func2 on func=
=20
and delete original func.
Is it so complex ?
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 16:49:15 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On Sunday, February 26, 2017 at 2:43:16 AM UTC-5, Denis Kotov wrote:
>>
>> Hi All,
>>
>> My proposal is very simple. Just remove completely forward references=20
>> because of confusion that it makes until it is not too late !!
>> Basically if we have the following example:
>>
>> template<typename T>
>> void setItem(T && t)
>> {
>> ...
>> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
>> =20
>> }
>>
>> But it confuses ( I think ) all of us.
>> Actually it even violates *SOLID *principale (S - Single=20
>> responsibility). I should use one function only for *rvalue *references=
=20
>> or for *lvalue *references. Mixing together handling of both references=
=20
>> is bad practice.
>>
>> What do you think ?
>>
>
> I think it will break every program that uses perfect forwarding. Which i=
s=20
> every program that ever does anything even remotely like:
>
> template<typename ...Args>
> void func(Args ...&&args)
> {
> return func2(std::forward<Args>(args)...);
> }
>
> Which means that `make/allocate_shared/unique` are broken. Every `emplace=
`=20
> function in the standard library is broken. And every such function that=
=20
> anyone over the last 6+ years has written is broken.
>
> That's a non-starter.
>
>
>
--=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/323f1df4-d94a-4b38-83a9-4d4268f844c1%40isocpp.or=
g.
------=_Part_675_1411237051.1488124171546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>But it is not so difficult ... little bit refact=
oring, change func2 on func and delete original func.</div><div>Is it so co=
mplex ?</div><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 26 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 16:4=
9:15 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Sunday, Febr=
uary 26, 2017 at 2:43:16 AM UTC-5, Denis Kotov wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Hi All,</div><div><br></div><div>My=
proposal is very simple. Just remove completely=C2=A0forward references be=
cause of confusion that it makes until it is not too late !!</div><div>Basi=
cally if we have the following example:</div><div><br></div><div>=C2=A0 =C2=
=A0 template<typename T></div><div>=C2=A0 =C2=A0 void setItem(T &=
& t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ..=
..</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rva=
lue </b>reference as all of you know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=
=C2=A0 =C2=A0 }</div><div><br></div><div>But it confuses ( I think ) all of=
us.</div><div>Actually it even violates <b>SOLID </b>principale (S - Singl=
e responsibility). I should use one function only for <b>rvalue </b>referen=
ces or for <b>lvalue </b>references. Mixing together handling of both refer=
ences is bad practice.</div><div><br></div><div>What do you think ?</div></=
div></blockquote><div><br>I think it will break every program that uses per=
fect forwarding. Which is every program that ever does anything even remote=
ly like:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span st=
yle=3D"color:#008">template</span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#008">typename</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">...</span><span style=3D"color:#606">Args</span><=
span style=3D"color:#660">></span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">void</span><span style=3D"color:#000"> func</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#606">Args</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">...&&=
</span><span style=3D"color:#000">args</span><span style=3D"color:#660">)</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">=
return</span><span style=3D"color:#000"> func2</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">std</span><span style=3D"color:#660=
">::</span><span style=3D"color:#000">forward</span><span style=3D"color:#6=
60"><</span><span style=3D"color:#606">Args</span><span style=3D"color:#=
660">>(</span><span style=3D"color:#000">args</span><span style=3D"color=
:#660">)<wbr>...);</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div><br>Which means that `make/alloc=
ate_shared/unique` are broken. Every `emplace` function in the standard lib=
rary is broken. And every such function that anyone over the last 6+ years =
has written is broken.<br><br>That's a non-starter.<br><br><br></div></=
div></blockquote></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/323f1df4-d94a-4b38-83a9-4d4268f844c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/323f1df4-d94a-4b38-83a9-4d4268f844c1=
%40isocpp.org</a>.<br />
------=_Part_675_1411237051.1488124171546--
------=_Part_674_992222847.1488124171545--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 26 Feb 2017 07:52:53 -0800 (PST)
Raw View
------=_Part_712_810419235.1488124373720
Content-Type: multipart/alternative;
boundary="----=_Part_713_30167439.1488124373720"
------=_Part_713_30167439.1488124373720
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It is due to ISO organization, but it does not mean that we should not do=
=20
it and wait until 2026 or whatever ...
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 17:30:14 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vicente =
J.=20
Botet Escriba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Le 26/02/2017 =C3=A0 08:43, Denis Kotov a =C3=A9crit :
>
> Hi All,
>
> My proposal is very simple. Just remove completely forward references=20
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
> =20
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single responsibility).=
=20
> I should use one function only for *rvalue *references or for *lvalue *re=
ferences.=20
> Mixing together handling of both references is bad practice.
>
> What do you think ?
>
>
> We need forwarding references, in order to forwarding transparently.
>
> You can propose something different for forwarding references or for=20
> rvalue references e.g. &&&. Then you will be able to deprecate something=
..
> Anyway. You couldn't have this before 2020 and the deprecation period=20
> would add still 6 years. So you will have the mixture until 2026 in the=
=20
> best case.
>
> You would need to master the current complexity until then ;-)
>
> Vicente
>
--=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/b1993997-af1c-4f84-9486-da359ff981f5%40isocpp.or=
g.
------=_Part_713_30167439.1488124373720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It is due to ISO organization, but it does not mean that w=
e should not do it and wait until 2026 or whatever ...<div><br>=D0=B2=D0=BE=
=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=84=D0=B5=D0=
=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 17:30:14 UTC+2 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vicente J. Botet Esc=
riba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 26/02/2017 =C3=A0 08:43, Denis Kotov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Hi All,</div>
<div><br>
</div>
<div>My proposal is very simple. Just remove completely=C2=A0forwar=
d
references because of confusion that it makes until it is not
too late !!</div>
<div>Basically if we have the following example:</div>
<div><br>
</div>
<div>=C2=A0 =C2=A0 template<typename T></div>
<div>=C2=A0 =C2=A0 void setItem(T && t)</div>
<div>=C2=A0 =C2=A0 {</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>lvalue </b>or <b>rv=
alue </b>reference
as all of you know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div>
<div>=C2=A0 =C2=A0 }</div>
<div><br>
</div>
<div>But it confuses ( I think ) all of us.</div>
<div>Actually it even violates <b>SOLID </b>principale (S -
Single responsibility). I should use one function only for <b>rva=
lue
</b>references or for <b>lvalue </b>references. Mixing
together handling of both references is bad practice.</div>
<div><br>
</div>
<div>What do you think ?</div>
</div>
</blockquote>
<br>
We need forwarding references, in order to forwarding transparently.<br=
>
<br>
You can propose something different for forwarding references or for
rvalue references=C2=A0 e.g. &&&. Then you will be able to
deprecate something.<br>
Anyway. You couldn't have this before 2020 and the deprecation
period would add still 6 years. So you will have the mixture until
2026 in the best case.<br>
<br>
You would need to master the current complexity until then ;-)<br>
<br>
Vicente<br>
</div>
</blockquote></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/b1993997-af1c-4f84-9486-da359ff981f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1993997-af1c-4f84-9486-da359ff981f5=
%40isocpp.org</a>.<br />
------=_Part_713_30167439.1488124373720--
------=_Part_712_810419235.1488124373720--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Feb 2017 08:05:49 -0800 (PST)
Raw View
------=_Part_4478_1289022193.1488125150033
Content-Type: multipart/alternative;
boundary="----=_Part_4479_2127312715.1488125150033"
------=_Part_4479_2127312715.1488125150033
Content-Type: text/plain; charset=UTF-8
On Sunday, February 26, 2017 at 10:49:31 AM UTC-5, Denis Kotov wrote:
>
> But it is not so difficult ... little bit refactoring, change func2 on
> func and delete original func.
> Is it so complex ?
>
Do not misconstrue a basic example as the *only example*. The point of the
example is that `func` might need to do some stuff before or after the call
to `func2`. Indeed, the ability to do that stuff is almost certainly *why
`func` exists*.
What you are proposing is *not gonna happen*. The committee is not going to
remove forwarding references just because they're not the best designed
feature in C++. They do their job, and tonnes of code out there depends on
them. Breaking all of that code, without providing a way to do what
forwarding references currently do, is a complete non-starter.
Also, please stop top-posting.
--
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/47a41662-d5e7-4cde-84e9-f303510c911f%40isocpp.org.
------=_Part_4479_2127312715.1488125150033
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 26, 2017 at 10:49:31 AM UTC-5, Denis K=
otov 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"><d=
iv><div>But it is not so difficult ... little bit refactoring, change func2=
on func and delete original func.</div><div>Is it so complex ?</div></div>=
</div></blockquote><div><br>Do not misconstrue a basic example as the <i>on=
ly example</i>. The point of the example is that `func` might need to do so=
me stuff before or after the call to `func2`. Indeed, the ability to do tha=
t stuff is almost certainly <i>why `func` exists</i>.<br><br>What you are p=
roposing is <i>not gonna happen</i>. The committee is not going to remove f=
orwarding references just because they're not the best designed feature=
in C++. They do their job, and tonnes of code out there depends on them. B=
reaking all of that code, without providing a way to do what forwarding ref=
erences currently do, is a complete non-starter.<br><br>Also, please stop t=
op-posting.</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/47a41662-d5e7-4cde-84e9-f303510c911f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47a41662-d5e7-4cde-84e9-f303510c911f=
%40isocpp.org</a>.<br />
------=_Part_4479_2127312715.1488125150033--
------=_Part_4478_1289022193.1488125150033--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Feb 2017 08:20:31 -0800 (PST)
Raw View
------=_Part_191_572853243.1488126031301
Content-Type: multipart/alternative;
boundary="----=_Part_192_1183585401.1488126031301"
------=_Part_192_1183585401.1488126031301
Content-Type: text/plain; charset=UTF-8
On Sunday, February 26, 2017 at 10:52:53 AM UTC-5, Denis Kotov wrote:
>
> It is due to ISO organization,
>
What is "due to ISO organization"? Having a sane backwards compatibility
policy like not breaking the world on a whim?
> but it does not mean that we should not do it and wait until 2026 or
> whatever ...
>
How do you suggest dealing with the breakage your suggestion would cause?
How would you suggest `emplace`-style functions or any other forwarding be
implemented? How do you deal with properly forwarding references to objects?
Because if you can't answer those questions, then your proposal is
il-conceived. You can't just say, "let's remove this and to hell with the
consequences." That's not a practical, reasonable 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/01da0820-b9eb-424f-8cf0-35a783dafafd%40isocpp.org.
------=_Part_192_1183585401.1488126031301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 26, 2017 at 10:52:53 AM UTC-5, Denis K=
otov 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">It=
is due to ISO organization,</div></blockquote><div><br>What is "due t=
o ISO organization"? Having a sane backwards compatibility policy like=
not breaking the world on a whim?<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">but it does not mean that we should no=
t do it and wait until 2026 or whatever ...</div></blockquote><div><br></di=
v>How do you suggest dealing with the breakage your suggestion would cause?=
How would you suggest `emplace`-style functions or any other forwarding be=
implemented? How do you deal with properly forwarding references to object=
s?<br><br>Because if you can't answer those questions, then your propos=
al is il-conceived. You can't just say, "let's remove this and=
to hell with the consequences." That's not a practical, reasonabl=
e idea.<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/01da0820-b9eb-424f-8cf0-35a783dafafd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01da0820-b9eb-424f-8cf0-35a783dafafd=
%40isocpp.org</a>.<br />
------=_Part_192_1183585401.1488126031301--
------=_Part_191_572853243.1488126031301--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 26 Feb 2017 09:56:47 -0800
Raw View
--001a113fac78fe17c6054972b062
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Nicol's right: we don't want to break the amount of code that simply
removing forwarding references would break. One could imagine proposing a
replacement, but the current syntax is going to have to stick around until
most people have migrated away from it. There would also need to be a
transition standard (at least 3 years on the current schedule) where the
current syntax is ill-formed, before we could re-use it for anything else.
That's not to say it was a good idea to overload the syntax=E2=80=94it's ju=
st a
mistake we can't fix any time soon.
Jeffrey
On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <redradist@gmail.com> wrote:
> Hi All,
>
> My proposal is very simple. Just remove completely forward references
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know
>
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single responsibility).
> I should use one function only for *rvalue *references or for *lvalue *re=
ferences.
> Mixing together handling of both references is bad practice.
>
> What do you think ?
>
> --
> 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/f4a47328-5397-4e93-
> 9453-ddb978256627%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4a47328-53=
97-4e93-9453-ddb978256627%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CANh-dX%3DK6GjQfdaM03a_qxVXdHPNaLeviO7K6rdyqv4Cw=
_Px7Q%40mail.gmail.com.
--001a113fac78fe17c6054972b062
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nicol's right: we don't want to break the amount o=
f code that simply removing forwarding references would break. One could im=
agine proposing a replacement, but the current syntax is going to have to s=
tick around until most people have migrated away from it. There would also =
need to be a transition standard (at least 3 years on the current schedule)=
where the current syntax is ill-formed, before we could re-use it for anyt=
hing else.<div><br></div><div>That's not to say it was a good idea to o=
verload the syntax=E2=80=94it's just a mistake we can't fix any tim=
e soon.</div><div><br></div><div>Jeffrey<br><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Sat, Feb 25, 2017 at 11:43 PM, Denis Kotov <s=
pan dir=3D"ltr"><<a href=3D"mailto:redradist@gmail.com" target=3D"_blank=
" class=3D"cremed">redradist@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Hi All,</div><div><br></div><div>=
My proposal is very simple. Just remove completely=C2=A0forward references =
because of confusion that it makes until it is not too late !!</div><div>Ba=
sically if we have the following example:</div><div><br></div><div>=C2=A0 =
=C2=A0 template<typename T></div><div>=C2=A0 =C2=A0 void setItem(T &a=
mp;& t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be <b>lvalue </b>or <b>=
rvalue </b>reference as all of you know =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><d=
iv>=C2=A0 =C2=A0 }</div><div><br></div><div>But it confuses ( I think ) all=
of us.</div><div>Actually it even violates <b>SOLID </b>principale (S - Si=
ngle responsibility). I should use one function only for <b>rvalue </b>refe=
rences or for <b>lvalue </b>references. Mixing together handling of both re=
ferences is bad practice.</div><div><br></div><div>What do you think ?</div=
></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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" target=3D"_=
blank" class=3D"cremed">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"cremed">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/f4a47328-5397-4e93-9453-ddb978256627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
class=3D"cremed">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<w=
br>proposals/f4a47328-5397-4e93-<wbr>9453-ddb978256627%40isocpp.org</a><wbr=
>.<br>
</font></span></blockquote></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" 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/CANh-dX%3DK6GjQfdaM03a_qxVXdHPNaLeviO=
7K6rdyqv4Cw_Px7Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DK6GjQ=
fdaM03a_qxVXdHPNaLeviO7K6rdyqv4Cw_Px7Q%40mail.gmail.com</a>.<br />
--001a113fac78fe17c6054972b062--
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Sun, 26 Feb 2017 12:57:14 -0600
Raw View
On Sun, Feb 26, 2017 at 9:30 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 26/02/2017 =C3=A0 08:43, Denis Kotov a =C3=A9crit :
>
> Hi All,
>
> My proposal is very simple. Just remove completely forward references
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be lvalue or rvalue reference as all of you know
> }
>
> But it confuses ( I think ) all of us.
> Actually it even violates SOLID principale (S - Single responsibility). I
> should use one function only for rvalue references or for lvalue referenc=
es.
> Mixing together handling of both references is bad practice.
>
> What do you think ?
+1
>
>
> We need forwarding references, in order to forwarding transparently.
>
> You can propose something different for forwarding references or for rval=
ue
> references e.g. &&&. Then you will be able to deprecate something.
> Anyway. You couldn't have this before 2020 and the deprecation period wou=
ld
> add still 6 years. So you will have the mixture until 2026 in the best ca=
se.
>
> You would need to master the current complexity until then ;-)
>
Not that I'm encouraging this, but even without introducing new syntax
(or constraining with concepts/enable_if or using constexpr_if), you
could twist class template argument deduction (which avoids creation
of forwarding references) to force the illusion (when you write your
function) that a particular syntax (T&&) connotes simple semantics
(always rvalue ref).
For e.g. instead of writing the following overloads:
template<class T> int* f(T&&); // ugh - be careful, can bind to both r and=
lval
template<class T> char* f(T&);
You could write the following:
// Write this as if it only handles Rvalues
template<class T> struct f {
int *ret;
f(T&& t) { ret =3D ... }
operator int*() { return ret; }
};
template<class T> f(T&) -> f<T&>;
// ... likewise for Lvalues
template<class T> struct f<T&> {
char *ret;
f(T& t) { ret =3D ... }
operator char*() { return ret; }
};
int i;
char *lval =3D f(i);
int *rval =3D f(0);
I know what you're thinking, because i'm thinking it too: "C++ - why
do you keep sleeping (and with whom ;) through the class on the KISS
principle?"
-faisal
>
> --
> 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/218337af-618=
b-4136-e864-615d9b153c1e%40wanadoo.fr.
--=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/CABsSThq-QU6wB_vZJAmO9rsXzXCAwy_swh2JFd3rtS95tM3=
xZg%40mail.gmail.com.
.
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Sun, 26 Feb 2017 13:11:51 -0600
Raw View
--94eb2c05eb343d6a46054973bc70
Content-Type: text/plain; charset=UTF-8
On Sun, Feb 26, 2017 at 1:43 AM, Denis Kotov <redradist@gmail.com> wrote:
>
> But it confuses ( I think ) all of us.
> Actually it even violates *SOLID *principale (S - Single responsibility).
> I should use one function only for *rvalue *references or for *lvalue *references.
> Mixing together handling of both references is bad practice.
>
> What do you think ?
>
>
>
If you think all code should be single-responsibility, then we should
remove templates from the language. The entire idea of generic programming
is being able to write code that works under a variety of scenarios. If you
don't think that generic programming is bad, then please explain why
forwarding arguments is evil and dangerous violation of
single-responsibility but vector is 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/CADbh%2BeQ1A6p07%2Bhu4YswGkz4Q%3DNoSHgfM3wBYn%2BwXOPFZG5b9A%40mail.gmail.com.
--94eb2c05eb343d6a46054973bc70
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 S=
un, Feb 26, 2017 at 1:43 AM, Denis Kotov <span dir=3D"ltr"><<a href=3D"m=
ailto:redradist@gmail.com" target=3D"_blank">redradist@gmail.com</a>></s=
pan> wrote:<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><br></d=
iv><div>But it confuses ( I think ) all of us.</div><div>Actually it even v=
iolates <b>SOLID </b>principale (S - Single responsibility). I should use o=
ne function only for <b>rvalue </b>references or for <b>lvalue </b>referenc=
es. Mixing together handling of both references is bad practice.</div><div>=
<br></div><div>What do you think ?</div></div><span class=3D"HOEnZb"><font =
color=3D"#888888">
<p></p><br></font></span></blockquote><div><br></div><div>If you think all =
code should be single-responsibility, then we should remove templates from =
the language. The entire idea of generic programming is being able to write=
code that works under a variety of scenarios. If you don't think that =
generic programming is bad, then please explain why forwarding arguments is=
evil and dangerous violation of single-responsibility but vector is not.</=
div></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" 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/CADbh%2BeQ1A6p07%2Bhu4YswGkz4Q%3DNoSH=
gfM3wBYn%2BwXOPFZG5b9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2Be=
Q1A6p07%2Bhu4YswGkz4Q%3DNoSHgfM3wBYn%2BwXOPFZG5b9A%40mail.gmail.com</a>.<br=
/>
--94eb2c05eb343d6a46054973bc70--
.
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Sun, 26 Feb 2017 13:13:39 -0600
Raw View
--94eb2c0653c0b58ce1054973c21d
Content-Type: text/plain; charset=UTF-8
On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <faisalv@gmail.com> wrote:
>
> For e.g. instead of writing the following overloads:
>
> template<class T> int* f(T&&); // ugh - be careful, can bind to both r
> and lval
> template<class T> char* f(T&);
>
> You could write the following:
>
> // Write this as if it only handles Rvalues
> template<class T> struct f {
> int *ret;
> f(T&& t) { ret = ... }
> operator int*() { return ret; }
> };
> template<class T> f(T&) -> f<T&>;
>
> // ... likewise for Lvalues
> template<class T> struct f<T&> {
> char *ret;
> f(T& t) { ret = ... }
> operator char*() { return ret; }
> };
>
> int i;
> char *lval = f(i);
> int *rval = f(0);
>
> I know what you're thinking, because i'm thinking it too: "C++ - why
> do you keep sleeping (and with whom ;) through the class on the KISS
> principle?"
> -faisal
>
If you think that your 11 lines of code is simpler than the 2 lines of code
you started with then we have very different definitions of simple.
--
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/CADbh%2BeSuRMxSDo3ubh4R78Q1_LuYEgnaZ5t0gceSKCk3m3622w%40mail.gmail.com.
--94eb2c0653c0b58ce1054973c21d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <span dir=3D"ltr"><<a =
href=3D"mailto:faisalv@gmail.com" target=3D"_blank">faisalv@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
For e.g. instead of writing the following overloads:<br>
<br>
template<class T> int* f(T&&);=C2=A0 // ugh - be careful, can=
bind to both r and lval<br>
template<class T> char* f(T&);<br>
<br>
You could write the following:<br>
<br>
// Write this as if it only handles Rvalues<br>
template<class T> struct f {<br>
=C2=A0 int *ret;<br>
=C2=A0 f(T&& t)=C2=A0 { ret =3D ... }<br>
=C2=A0 operator int*() { return ret; }<br>
};<br>
template<class T> f(T&) -> f<T&>;<br>
<br>
// ... likewise for Lvalues<br>
template<class T> struct f<T&> {<br>
=C2=A0 char *ret;<br>
=C2=A0 f(T& t) { ret =3D ... }<br>
=C2=A0 operator char*() { return ret; }<br>
};<br>
<br>
int i;<br>
char *lval =3D f(i);<br>
int *rval =3D f(0);<br>
<br>
I know what you're thinking, because i'm thinking it too: "C++=
- why<br>
do you keep sleeping (and with whom ;) through the class on the KISS<br>
principle?"<br>
-faisal<br></blockquote><div><br></div><div>If you think that your 11 lines=
of code is simpler than the 2 lines of code you started with then we have =
very different definitions of simple.</div></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" 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/CADbh%2BeSuRMxSDo3ubh4R78Q1_LuYEgnaZ5=
t0gceSKCk3m3622w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeSuRMxS=
Do3ubh4R78Q1_LuYEgnaZ5t0gceSKCk3m3622w%40mail.gmail.com</a>.<br />
--94eb2c0653c0b58ce1054973c21d--
.
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Sun, 26 Feb 2017 13:20:22 -0600
Raw View
--001a1149a01cafdb23054973dae4
Content-Type: text/plain; charset=UTF-8
I think most of the confusion around T&& binding exists because:
1) people don't realize that templates can take reference types, eg.
foo<const int&>();
2) people don't think about what should happen if you create an lvalue
reference to an rvalue reference.
If this is really something we feel the need to solve then there is a
simple solution that doesn't damage any existing code. Just make an rvalue
reference qualifier that cannot collapse against lvalue reference. Suppose
this syntax is T&&&.
so
template<class T>
void foo(T&&& t);
int a = 0;
foo(0); //ok
foo(a); //ill formed because reference collapsing fails (int& &&& can't be
collapsed)
All existing code continues to work and you now have a shorthand notation
for what currently requires enable_if.
On Sun, Feb 26, 2017 at 1:13 PM, Brittany Friedman <fourthgeek@gmail.com>
wrote:
>
>
> On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <faisalv@gmail.com> wrote:
>
>>
>> For e.g. instead of writing the following overloads:
>>
>> template<class T> int* f(T&&); // ugh - be careful, can bind to both r
>> and lval
>> template<class T> char* f(T&);
>>
>> You could write the following:
>>
>> // Write this as if it only handles Rvalues
>> template<class T> struct f {
>> int *ret;
>> f(T&& t) { ret = ... }
>> operator int*() { return ret; }
>> };
>> template<class T> f(T&) -> f<T&>;
>>
>> // ... likewise for Lvalues
>> template<class T> struct f<T&> {
>> char *ret;
>> f(T& t) { ret = ... }
>> operator char*() { return ret; }
>> };
>>
>> int i;
>> char *lval = f(i);
>> int *rval = f(0);
>>
>> I know what you're thinking, because i'm thinking it too: "C++ - why
>> do you keep sleeping (and with whom ;) through the class on the KISS
>> principle?"
>> -faisal
>>
>
> If you think that your 11 lines of code is simpler than the 2 lines of
> code you started with then we have very different definitions of simple.
>
>
--
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/CADbh%2BeRnQdMngA8vPFVLBAsR7fwsR81-LBvbBe6pLV%3D5VZQiSw%40mail.gmail.com.
--001a1149a01cafdb23054973dae4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think most of the confusion around T&& binding e=
xists because:<div>1) people don't realize that templates can take refe=
rence types, eg. foo<const int&>();</div><div>2) people don't=
think about what should happen if you create an lvalue reference to an rva=
lue reference.</div><div><br></div><div>If this is really something we feel=
the need to solve then there is a simple solution that doesn't damage =
any existing code. Just make an rvalue reference qualifier that cannot coll=
apse against lvalue reference. Suppose this syntax is T&&&.</di=
v><div><br></div><div>so</div><div>template<class T></div><div>void f=
oo(T&&& t);</div><div><br></div><div>int a =3D 0;</div><div>foo=
(0); //ok</div><div>foo(a); //ill formed because reference collapsing fails=
(int& &&& can't be collapsed)</div><div><br></div><div=
>All existing code continues to work and you now have a shorthand notation =
for what currently requires enable_if.</div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Feb 26, 2017 at 1:1=
3 PM, Brittany Friedman <span dir=3D"ltr"><<a href=3D"mailto:fourthgeek@=
gmail.com" target=3D"_blank">fourthgeek@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote"><span class=3D"">On Sun, Feb 26, 2017 at=
12:57 PM, Faisal Vali <span dir=3D"ltr"><<a href=3D"mailto:faisalv@gmai=
l.com" target=3D"_blank">faisalv@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><br>
For e.g. instead of writing the following overloads:<br>
<br>
template<class T> int* f(T&&);=C2=A0 // ugh - be careful, can=
bind to both r and lval<br>
template<class T> char* f(T&);<br>
<br>
You could write the following:<br>
<br>
// Write this as if it only handles Rvalues<br>
template<class T> struct f {<br>
=C2=A0 int *ret;<br>
=C2=A0 f(T&& t)=C2=A0 { ret =3D ... }<br>
=C2=A0 operator int*() { return ret; }<br>
};<br>
template<class T> f(T&) -> f<T&>;<br>
<br>
// ... likewise for Lvalues<br>
template<class T> struct f<T&> {<br>
=C2=A0 char *ret;<br>
=C2=A0 f(T& t) { ret =3D ... }<br>
=C2=A0 operator char*() { return ret; }<br>
};<br>
<br>
int i;<br>
char *lval =3D f(i);<br>
int *rval =3D f(0);<br>
<br>
I know what you're thinking, because i'm thinking it too: "C++=
- why<br>
do you keep sleeping (and with whom ;) through the class on the KISS<br>
principle?"<br>
-faisal<br></blockquote><div><br></div></span><div>If you think that your 1=
1 lines of code is simpler than the 2 lines of code you started with then w=
e have very different definitions of simple.</div></div><br></div></div>
</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" 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/CADbh%2BeRnQdMngA8vPFVLBAsR7fwsR81-LB=
vbBe6pLV%3D5VZQiSw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRnQd=
MngA8vPFVLBAsR7fwsR81-LBvbBe6pLV%3D5VZQiSw%40mail.gmail.com</a>.<br />
--001a1149a01cafdb23054973dae4--
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Sun, 26 Feb 2017 13:32:50 -0600
Raw View
On Sun, Feb 26, 2017 at 1:13 PM, Brittany Friedman <fourthgeek@gmail.com> wrote:
>
>
> On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <faisalv@gmail.com> wrote:
>>
>>
>> For e.g. instead of writing the following overloads:
>>
>> template<class T> int* f(T&&); // ugh - be careful, can bind to both r
>> and lval
>> template<class T> char* f(T&);
>>
>> You could write the following:
>>
>> // Write this as if it only handles Rvalues
>> template<class T> struct f {
>> int *ret;
>> f(T&& t) { ret = ... }
>> operator int*() { return ret; }
>> };
>> template<class T> f(T&) -> f<T&>;
>>
>> // ... likewise for Lvalues
>> template<class T> struct f<T&> {
>> char *ret;
>> f(T& t) { ret = ... }
>> operator char*() { return ret; }
>> };
>>
>> int i;
>> char *lval = f(i);
>> int *rval = f(0);
>>
>> I know what you're thinking, because i'm thinking it too: "C++ - why
>> do you keep sleeping (and with whom ;) through the class on the KISS
>> principle?"
>> -faisal
>
>
> If you think that your 11 lines of code is simpler than the 2 lines of code
> you started with then we have very different definitions of simple.
>
?!?
My sarcastic post and denouement regarding C++ evolution was meant as
an indictment of having to even consider those 11 lines of code (as
opposed to the two) as a potential solution. (Does having to explain
sarcasm, suggest a failure in one's ability to wield it? I guess, like
C++, the practice of sardonicity isn't as simple as one would like it
to be;)
> --
> 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/CADbh%2BeSuRMxSDo3ubh4R78Q1_LuYEgnaZ5t0gceSKCk3m3622w%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/CABsSThod-n_8xezUMan-GxDTqD%3DxsxF3gUn%2B1qiq8nsDTE7BEw%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Feb 2017 11:39:18 -0800 (PST)
Raw View
------=_Part_4995_450115296.1488137958201
Content-Type: multipart/alternative;
boundary="----=_Part_4996_915641181.1488137958201"
------=_Part_4996_915641181.1488137958201
Content-Type: text/plain; charset=UTF-8
On Sunday, February 26, 2017 at 2:20:23 PM UTC-5, Brent Friedman wrote:
>
> I think most of the confusion around T&& binding exists because:
> 1) people don't realize that templates can take reference types, eg.
> foo<const int&>();
> 2) people don't think about what should happen if you create an lvalue
> reference to an rvalue reference.
>
I disagree. It is confusing because `Typename&&` and `T&&` behave
differently, even though `Typename&` and `T&` behave the same. In the
latter case, the template will directly refuse temporaries and xvalues,
just like `Typename&`. Whereas the former case, the template version will
accept lvalues despite `Typename&&` refusing them.
That's the source of the confusion: the inconsistency between the way a
template parameter behaves and the way an explicit type's parameter
behaves. The rules about template deduction, reference collapsing, all that
is just what *causes* the inconsistency. It's the inconsistency itself that
creates the problem.
If this were 2009, changing it would be a really good idea. This is however
2017; it's too late to go breaking everyone's code just because something
is a bit confused.
--
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/4d8f9170-0b2a-4fed-8462-94c0d3ec8e19%40isocpp.org.
------=_Part_4996_915641181.1488137958201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 26, 2017 at 2:20:23 PM UTC-5, Brent Fr=
iedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I think most of the confusion around T&& binding exists because:<di=
v>1) people don't realize that templates can take reference types, eg. =
foo<const int&>();</div><div>2) people don't think about what=
should happen if you create an lvalue reference to an rvalue reference.</d=
iv></div></blockquote><div><br>I disagree. It is confusing because `Typenam=
e&&` and `T&&` behave differently, even though `Typename&am=
p;` and `T&` behave the same. In the latter case, the template will dir=
ectly refuse temporaries and xvalues, just like `Typename&`. Whereas th=
e former case, the template version will accept lvalues despite `Typename&a=
mp;&` refusing them.<br><br>That's the source of the confusion: the=
inconsistency between the way a template parameter behaves and the way an =
explicit type's parameter behaves. The rules about template deduction, =
reference collapsing, all that is just what <i>causes</i> the inconsistency=
.. It's the inconsistency itself that creates the problem.<br><br>If thi=
s were 2009, changing it would be a really good idea. This is however 2017;=
it's too late to go breaking everyone's code just because somethin=
g is a bit confused.</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/4d8f9170-0b2a-4fed-8462-94c0d3ec8e19%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4d8f9170-0b2a-4fed-8462-94c0d3ec8e19=
%40isocpp.org</a>.<br />
------=_Part_4996_915641181.1488137958201--
------=_Part_4995_450115296.1488137958201--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Feb 2017 11:43:10 -0800 (PST)
Raw View
------=_Part_4654_797953684.1488138190633
Content-Type: multipart/alternative;
boundary="----=_Part_4655_1701279089.1488138190633"
------=_Part_4655_1701279089.1488138190633
Content-Type: text/plain; charset=UTF-8
On Sunday, February 26, 2017 at 2:33:22 PM UTC-5, faisalv wrote:
>
> On Sun, Feb 26, 2017 at 1:13 PM, Brittany Friedman <fourt...@gmail.com
> <javascript:>> wrote:
> >
> >
> > On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <fai...@gmail.com
> <javascript:>> wrote:
> >>
> >>
> >> For e.g. instead of writing the following overloads:
> >>
> >> template<class T> int* f(T&&); // ugh - be careful, can bind to both r
> >> and lval
> >> template<class T> char* f(T&);
> >>
> >> You could write the following:
> >>
> >> // Write this as if it only handles Rvalues
> >> template<class T> struct f {
> >> int *ret;
> >> f(T&& t) { ret = ... }
> >> operator int*() { return ret; }
> >> };
> >> template<class T> f(T&) -> f<T&>;
> >>
> >> // ... likewise for Lvalues
> >> template<class T> struct f<T&> {
> >> char *ret;
> >> f(T& t) { ret = ... }
> >> operator char*() { return ret; }
> >> };
> >>
> >> int i;
> >> char *lval = f(i);
> >> int *rval = f(0);
> >>
> >> I know what you're thinking, because i'm thinking it too: "C++ - why
> >> do you keep sleeping (and with whom ;) through the class on the KISS
> >> principle?"
> >> -faisal
> >
> >
> > If you think that your 11 lines of code is simpler than the 2 lines of
> code
> > you started with then we have very different definitions of simple.
> >
>
> ?!?
> My sarcastic post and denouement regarding C++ evolution was meant as
> an indictment of having to even consider those 11 lines of code (as
> opposed to the two) as a potential solution. (Does having to explain
> sarcasm, suggest a failure in one's ability to wield it? I guess, like
> C++, the practice of sardonicity isn't as simple as one would like it
> to be;)
>
When attempting to employ sarcasm, it's always important to remember the
context of the discussion. We're in a discussion with a user who *genuinely
believes* that it's perfectly OK to break the entire C++ world just to get
rid of an inconsistency, while simultaneously leaving a massive usability
gap in the language (forwarding). Poe's Law
<https://en.wikipedia.org/wiki/Poe%27s_Law>applies to programming
extremists just as much as non-programmers.
Failing that, adding </sarcasm> always helps ;)
--
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/d611fc09-7399-4d27-9196-133eeab8592a%40isocpp.org.
------=_Part_4655_1701279089.1488138190633
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 26, 2017 at 2:33:22 PM UTC-5, faisalv =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Feb 26, 2017 at =
1:13 PM, Brittany Friedman <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"pB6mxuG2AgAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">fourt...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Sun, Feb 26, 2017 at 12:57 PM, Faisal Vali <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pB6mxuG2AgAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">fai...@gmail.com</a>&=
gt; wrote:
<br>>>
<br>>>
<br>>> For e.g. instead of writing the following overloads:
<br>>>
<br>>> template<class T> int* f(T&&); =C2=A0// ugh - be=
careful, can bind to both r
<br>>> and lval
<br>>> template<class T> char* f(T&);
<br>>>
<br>>> You could write the following:
<br>>>
<br>>> // Write this as if it only handles Rvalues
<br>>> template<class T> struct f {
<br>>> =C2=A0 int *ret;
<br>>> =C2=A0 f(T&& t) =C2=A0{ ret =3D ... }
<br>>> =C2=A0 operator int*() { return ret; }
<br>>> };
<br>>> template<class T> f(T&) -> f<T&>;
<br>>>
<br>>> // ... likewise for Lvalues
<br>>> template<class T> struct f<T&> {
<br>>> =C2=A0 char *ret;
<br>>> =C2=A0 f(T& t) { ret =3D ... }
<br>>> =C2=A0 operator char*() { return ret; }
<br>>> };
<br>>>
<br>>> int i;
<br>>> char *lval =3D f(i);
<br>>> int *rval =3D f(0);
<br>>>
<br>>> I know what you're thinking, because i'm thinking it t=
oo: "C++ - why
<br>>> do you keep sleeping (and with whom ;) through the class on th=
e KISS
<br>>> principle?"
<br>>> -faisal
<br>>
<br>>
<br>> If you think that your 11 lines of code is simpler than the 2 line=
s of code
<br>> you started with then we have very different definitions of simple=
..
<br>>
<br>
<br>?!?
<br>My sarcastic post and denouement regarding C++ evolution was meant as
<br>an indictment of having to even consider those 11 lines of code (as
<br>opposed to the two) as a potential solution. =C2=A0(Does having to expl=
ain
<br>sarcasm, suggest a failure in one's ability to wield it? I guess, l=
ike
<br>C++, the practice of sardonicity isn't as simple as one would like =
it
<br>to be;)<br></blockquote><div><br>When attempting to employ sarcasm, it&=
#39;s always important to remember the context of the discussion. We're=
in a discussion with a user who <i>genuinely believes</i> that it's pe=
rfectly OK to break the entire C++ world just to get rid of an inconsistenc=
y, while simultaneously leaving a massive usability gap in the language (fo=
rwarding). <a href=3D"https://en.wikipedia.org/wiki/Poe%27s_Law">Poe's =
Law </a>applies to programming extremists just as much as non-programmers.<=
br><br>Failing that, adding </sarcasm> always helps ;)<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/d611fc09-7399-4d27-9196-133eeab8592a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d611fc09-7399-4d27-9196-133eeab8592a=
%40isocpp.org</a>.<br />
------=_Part_4655_1701279089.1488138190633--
------=_Part_4654_797953684.1488138190633--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Mon, 27 Feb 2017 11:45:31 -0800 (PST)
Raw View
------=_Part_1033_123125502.1488224732063
Content-Type: multipart/alternative;
boundary="----=_Part_1034_1780569094.1488224732063"
------=_Part_1034_1780569094.1488224732063
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
You've got my point !!
But it is right now time to fix it.
Every time somebody says it is bad, but we cannot break all other code ...=
=20
after 6 year (2023) since this time somebody will say: "We have more over=
=20
code and right now we cannot do it, we had to fix it 6 years earlier" ...=
=20
after 10 year we will heard it again ... and so
My point is that for C++ 6 years from 2011 is nothing for C++
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 21:39:18 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Sunday, February 26, 2017 at 2:20:23 PM UTC-5, Brent Friedman wrote:
>>
>> I think most of the confusion around T&& binding exists because:
>> 1) people don't realize that templates can take reference types, eg.=20
>> foo<const int&>();
>> 2) people don't think about what should happen if you create an lvalue=
=20
>> reference to an rvalue reference.
>>
>
> I disagree. It is confusing because `Typename&&` and `T&&` behave=20
> differently, even though `Typename&` and `T&` behave the same. In the=20
> latter case, the template will directly refuse temporaries and xvalues,=
=20
> just like `Typename&`. Whereas the former case, the template version will=
=20
> accept lvalues despite `Typename&&` refusing them.
>
> That's the source of the confusion: the inconsistency between the way a=
=20
> template parameter behaves and the way an explicit type's parameter=20
> behaves. The rules about template deduction, reference collapsing, all th=
at=20
> is just what *causes* the inconsistency. It's the inconsistency itself=20
> that creates the problem.
>
> If this were 2009, changing it would be a really good idea. This is=20
> however 2017; it's too late to go breaking everyone's code just because=
=20
> something is a bit confused.
>
--=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/c27b6d29-cf4b-471d-a4fe-99849df6c6ea%40isocpp.or=
g.
------=_Part_1034_1780569094.1488224732063
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You've got my point !!<div><br></div><div>But it is ri=
ght now time to fix it.</div><div>Every time somebody says it is bad, but w=
e cannot break all other code ... after 6 year (2023) since this time someb=
ody will say: "We have more over code and right now we cannot do it, w=
e had to fix it 6 years earlier" ... after 10 year we will heard it ag=
ain ... and so</div><div><br></div><div>My point is that for C++ 6 years fr=
om 2011 is nothing for C++<br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=
=81=D0=B5=D0=BD=D1=8C=D0=B5, 26 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F =
2017 =D0=B3., 21:39:18 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=
=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=BB:<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 =
Sunday, February 26, 2017 at 2:20:23 PM UTC-5, Brent Friedman wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think most of the confu=
sion around T&& binding exists because:<div>1) people don't rea=
lize that templates can take reference types, eg. foo<const int&>=
();</div><div>2) people don't think about what should happen if you cre=
ate an lvalue reference to an rvalue reference.</div></div></blockquote><di=
v><br>I disagree. It is confusing because `Typename&&` and `T&&=
amp;` behave differently, even though `Typename&` and `T&` behave t=
he same. In the latter case, the template will directly refuse temporaries =
and xvalues, just like `Typename&`. Whereas the former case, the templa=
te version will accept lvalues despite `Typename&&` refusing them.<=
br><br>That's the source of the confusion: the inconsistency between th=
e way a template parameter behaves and the way an explicit type's param=
eter behaves. The rules about template deduction, reference collapsing, all=
that is just what <i>causes</i> the inconsistency. It's the inconsiste=
ncy itself that creates the problem.<br><br>If this were 2009, changing it =
would be a really good idea. This is however 2017; it's too late to go =
breaking everyone's code just because something is a bit confused.</div=
></div></blockquote></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/c27b6d29-cf4b-471d-a4fe-99849df6c6ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c27b6d29-cf4b-471d-a4fe-99849df6c6ea=
%40isocpp.org</a>.<br />
------=_Part_1034_1780569094.1488224732063--
------=_Part_1033_123125502.1488224732063--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 27 Feb 2017 11:51:45 -0800 (PST)
Raw View
------=_Part_7050_1470126613.1488225105152
Content-Type: multipart/alternative;
boundary="----=_Part_7051_1106779844.1488225105153"
------=_Part_7051_1106779844.1488225105153
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, February 25, 2017 at 11:43:16 PM UTC-8, Denis Kotov wrote:
>
>
> My proposal is very simple. Just remove completely forward references=20
> because of confusion that it makes until it is not too late !!
> Basically if we have the following example:
>
> template<typename T>
> void setItem(T && t)
> {
> ...
> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
> =20
> }
>
> But it confuses ( I think ) all of us.
>
Nope! Reference collapsing has been in the language since 1998, although=
=20
its exact semantics were not standardized until 2011 as far as I know.
If you find reference collapsing confusing, I suggest that you watch my=20
CppCon 2016 talk "Template Normal Programming"[1], which covers the=20
difference between lvalue and rvalue references and explains the rule for=
=20
collapsing them together. (In short: if anyone else in the world claims to=
=20
care about an object, you're not allowed to disembowel that object.) Once=
=20
you understand reference collapsing, "forwarding references" (formerly=20
known as "universal references", formerly known as "just this particular=20
syntax for exploiting reference collapsing in template contexts") falls out=
=20
naturally.
So it would be reasonable (IMHO) to say that the term "forwarding=20
reference" is unnecessary and therefore confusing; but personally I find it=
=20
useful to have a term for the thing that's less cumbersome than "this=20
particular syntax for exploiting reference collapsing" or "an rvalue=20
reference to a cv-unqualified template parameter that does not represent a=
=20
template parameter of a class template" or whatever.
HTH,
=E2=80=93Arthur
[1] - https://www.youtube.com/watch?v=3DvwrXHznaYLA (circa the 35-minute ma=
rk)
--=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/69c0683c-3b36-4de4-941d-9487366615d6%40isocpp.or=
g.
------=_Part_7051_1106779844.1488225105153
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, February 25, 2017 at 11:43:16 PM UTC-8, Denis=
Kotov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br></div><div>My proposal is very simple. Just remove completely=C2=
=A0forward references because of confusion that it makes until it is not to=
o late !!</div><div>Basically if we have the following example:</div><div><=
br></div><div>=C2=A0 =C2=A0 template<typename T></div><div>=C2=A0 =C2=
=A0 void setItem(T && t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can be=
<b>lvalue </b>or <b>rvalue </b>reference as all of you know =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>But it con=
fuses ( I think ) all of us.</div></div></blockquote><div><br></div><div>No=
pe! =C2=A0Reference collapsing has been in the language since 1998, althoug=
h its exact semantics were not standardized until 2011 as far as I know.</d=
iv><div>If you find reference collapsing confusing, I suggest that you watc=
h my CppCon 2016 talk "Template Normal Programming"[1], which cov=
ers the difference between lvalue and rvalue references and explains the ru=
le for collapsing them together. (In short: if anyone else in the world cla=
ims to care about an object, you're not allowed to disembowel that obje=
ct.) =C2=A0Once you understand reference collapsing, "forwarding refer=
ences" (formerly known as "universal references", formerly k=
nown as "just this particular syntax for exploiting reference collapsi=
ng in template contexts") falls out naturally.</div><div><br></div><di=
v>So it would be reasonable (IMHO) to say that the term "forwarding re=
ference" is unnecessary and therefore confusing; but personally I find=
it useful to have a term for the thing that's less cumbersome than &qu=
ot;this particular syntax for exploiting reference collapsing" or &quo=
t;an rvalue reference to a cv-unqualified template parameter that does not =
represent a template parameter of a class template" or whatever.</div>=
<div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div><div><br></div><div=
>[1] -=C2=A0https://www.youtube.com/watch?v=3DvwrXHznaYLA (circa the 35-min=
ute mark)</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/69c0683c-3b36-4de4-941d-9487366615d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69c0683c-3b36-4de4-941d-9487366615d6=
%40isocpp.org</a>.<br />
------=_Part_7051_1106779844.1488225105153--
------=_Part_7050_1470126613.1488225105152--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Mon, 27 Feb 2017 12:39:16 -0800 (PST)
Raw View
------=_Part_566_1195474651.1488227956580
Content-Type: multipart/alternative;
boundary="----=_Part_567_1679961290.1488227956581"
------=_Part_567_1679961290.1488227956581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks you for answer, Arthur
I have seen your video and understand reference collapsing.
In this case I have two questions:
1) But do not you think it is confusing ?
2) Do not you think if I have tempate like this:
template<typename T>
void run(T && t)
{
// I want to be sure that t is rvalue and I can catch all data that=
=20
are stored in it because anyway it will be deleted after this function
}
template<typename T>
void run(T & t)
{
// I know exactly that t is lvalue and I cannot do nothing bad with=
=20
data of this structure
}
3) If you anyway think that forwarding reference is useful, can you give an=
=20
example of usefulness ?
Thanks,
Denis
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 27 =D1=
=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 21:51:45 UTC+2 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Arthur O=
'Dwyer=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Saturday, February 25, 2017 at 11:43:16 PM UTC-8, Denis Kotov wrote:
>>
>>
>> My proposal is very simple. Just remove completely forward references=20
>> because of confusion that it makes until it is not too late !!
>> Basically if we have the following example:
>>
>> template<typename T>
>> void setItem(T && t)
>> {
>> ...
>> // T can be *lvalue *or *rvalue *reference as all of you know =
=20
>> =20
>> }
>>
>> But it confuses ( I think ) all of us.
>>
>
> Nope! Reference collapsing has been in the language since 1998, although=
=20
> its exact semantics were not standardized until 2011 as far as I know.
> If you find reference collapsing confusing, I suggest that you watch my=
=20
> CppCon 2016 talk "Template Normal Programming"[1], which covers the=20
> difference between lvalue and rvalue references and explains the rule for=
=20
> collapsing them together. (In short: if anyone else in the world claims t=
o=20
> care about an object, you're not allowed to disembowel that object.) Onc=
e=20
> you understand reference collapsing, "forwarding references" (formerly=20
> known as "universal references", formerly known as "just this particular=
=20
> syntax for exploiting reference collapsing in template contexts") falls o=
ut=20
> naturally.
>
> So it would be reasonable (IMHO) to say that the term "forwarding=20
> reference" is unnecessary and therefore confusing; but personally I find =
it=20
> useful to have a term for the thing that's less cumbersome than "this=20
> particular syntax for exploiting reference collapsing" or "an rvalue=20
> reference to a cv-unqualified template parameter that does not represent =
a=20
> template parameter of a class template" or whatever.
>
> HTH,
> =E2=80=93Arthur
>
> [1] - https://www.youtube.com/watch?v=3DvwrXHznaYLA (circa the 35-minute=
=20
> mark)
>
--=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/77fd5ab0-76dc-47d5-b0cc-cd7f0a32f921%40isocpp.or=
g.
------=_Part_567_1679961290.1488227956581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks you for answer, Arthur<div><br></div><div>I have se=
en your video and understand reference collapsing.</div><div><br></div><div=
>In this case I have two questions:</div><div>1) But do not you think it is=
confusing ?</div><div>2) Do not you think if I have tempate like this:</di=
v><div><br></div><div>=C2=A0 =C2=A0 template<typename T></div><div>=
=C2=A0 =C2=A0 void run(T && t)</div><div>=C2=A0 =C2=A0 {</div><div>=
=C2=A0 =C2=A0 =C2=A0 // I want to be sure that t is rvalue and I can catch =
all data that are stored in it because anyway it will be deleted after this=
function</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div><div>=C2=A0 =
=C2=A0 template<typename T></div><div>=C2=A0 =C2=A0 void run(T & =
t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 // I know exact=
ly that t is lvalue and I cannot do nothing bad with data of this structure=
</div><div>=C2=A0 =C2=A0 }</div><div><br></div>3) If you anyway think that =
forwarding reference is useful, can you give an example of usefulness ?</di=
v><div><br></div><div>Thanks,</div><div>Denis</div><div><br>=D0=BF=D0=BE=D0=
=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 27 =D1=84=D0=B5=D0=B2=
=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 21:51:45 UTC+2 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Arthur O'Dwyer =D0=
=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">On Saturday, February 25, 2017 at 11:43:16 PM UT=
C-8, Denis Kotov 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"><div><br></div><div>My proposal is very simple. Just remove completely=
=C2=A0forward references because of confusion that it makes until it is not=
too late !!</div><div>Basically if we have the following example:</div><di=
v><br></div><div>=C2=A0 =C2=A0 template<typename T></div><div>=C2=A0 =
=C2=A0 void setItem(T && t)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // T can=
be <b>lvalue </b>or <b>rvalue </b>reference as all of you know =C2=A0 =C2=
=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>But it=
confuses ( I think ) all of us.</div></div></blockquote><div><br></div><di=
v>Nope! =C2=A0Reference collapsing has been in the language since 1998, alt=
hough its exact semantics were not standardized until 2011 as far as I know=
..</div><div>If you find reference collapsing confusing, I suggest that you =
watch my CppCon 2016 talk "Template Normal Programming"[1], which=
covers the difference between lvalue and rvalue references and explains th=
e rule for collapsing them together. (In short: if anyone else in the world=
claims to care about an object, you're not allowed to disembowel that =
object.) =C2=A0Once you understand reference collapsing, "forwarding r=
eferences" (formerly known as "universal references", former=
ly known as "just this particular syntax for exploiting reference coll=
apsing in template contexts") falls out naturally.</div><div><br></div=
><div>So it would be reasonable (IMHO) to say that the term "forwardin=
g reference" is unnecessary and therefore confusing; but personally I =
find it useful to have a term for the thing that's less cumbersome than=
"this particular syntax for exploiting reference collapsing" or =
"an rvalue reference to a cv-unqualified template parameter that does =
not represent a template parameter of a class template" or whatever.</=
div><div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div><div><br></div>=
<div>[1] -=C2=A0<a href=3D"https://www.youtube.com/watch?v=3DvwrXHznaYLA" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://w=
ww.youtube.com/watch?v\x3dvwrXHznaYLA';return true;" onclick=3D"this.hr=
ef=3D'https://www.youtube.com/watch?v\x3dvwrXHznaYLA';return true;"=
>https://www.youtube.com/<wbr>watch?v=3DvwrXHznaYLA</a> (circa the 35-minut=
e mark)</div></div></blockquote></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/77fd5ab0-76dc-47d5-b0cc-cd7f0a32f921%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77fd5ab0-76dc-47d5-b0cc-cd7f0a32f921=
%40isocpp.org</a>.<br />
------=_Part_567_1679961290.1488227956581--
------=_Part_566_1195474651.1488227956580--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 27 Feb 2017 15:13:53 -0800
Raw View
--94eb2c07654cb2d3ee05498b3bdc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 27, 2017 at 12:39 PM, Denis Kotov <redradist@gmail.com> wrote:
> Thanks you for answer, Arthur
>
> I have seen your video and understand reference collapsing.
>
> In this case I have two questions:
> 1) But do not you think it is confusing ?
>
I think it's as "confusing" as e.g. the fact that we have two versions of
operator++ (one taking no arguments and the other taking "int"), or that
the rules for template type deduction are different between function
templates and class templates (even in C++17). That is,none of these are
things you're likely to work out from first principles yourself. But once
it's explained to you once, it's easy to remember and apply the rule in a
variety of everyday situations.
2) Do not you think if I have tempate like this:
>
> template<typename T>
> void run(T && t)
> {
> // I want to be sure that t is rvalue and I can catch all data that
> are stored in it because anyway it will be deleted after this function
> }
>
> template<typename T>
> void run(T & t)
> {
> // I know exactly that t is lvalue and I cannot do nothing bad with
> data of this structure
> }
>
Wrong. http://melpon.org/wandbox/permlink/Uw1UnuCVJgk2ppvh
Be careful with your terminology here. Your comments are currently wrong.
What you should say is
template<typename T> void run(T&& t)
{
// As far as my caller is concerned, I promise not to hold onto a
reference to t
}
template<typename T> void run(T& t)
{
// As far as my caller is concerned, I require the ability to hold onto
a reference to t
}
Therefore it is legitimate to pass rvalues to run(T&&), but it is not
legitimate to pass rvalues to run(T&) (because if the caller believes that
he's holding an rvalue, there's no way for the caller to satisfy run(T&)'s
request for an lvalue).
3) If you anyway think that forwarding reference is useful, can you give an
> example of usefulness ?
>
std::invoke. std::forward. std::forward_as_tuple. std::make_tuple.
std::make_unique. std::make_shared. std::vector::emplace.
std::map::emplace. Basically, any function or constructor that you can
currently imagine passing std::move(x) to, or any function or constructor
whose semantics are defined in terms of "perfect forwarding".
When you ask for the abolition of perfect forwarding, you're basically
asking for the abolition of C++11 rvalue semantics; this is why your
request isn't getting a whole lot of traction.
By the way, if you want to ensure that a certain function accepts nothing
but rvalues from its caller, I believe you could write
template<typename T, typename E =3D std::enable_if_t<!std::is_reference_v<T=
>>>
void run(T&& t)
{
// As far as my caller is concerned, I promise not to hold onto a
reference to t...
// and I also REQUIRE that my CALLER not hold onto such a reference
either!
}
But I find it hard to imagine a case where this behavior would actually be
useful. The only reason to accept specifically an rvalue is because you
plan to disembowel the rvalue and use its guts for something else. Under
the current rules, disemboweling-or-not happens naturally and appropriately
due to copy/move semantics and perfect forwarding. You're wanting to write
a function that *unconditionally disembowels* its argument, and then asking
for a way to make that "safe". I'm saying that unconditionally
disemboweling things is not the C++ way. Besides, how would you even know
how to gut an object if you didn't know its type?
template<typename T, typename E =3D std::enable_if_t<!std::is_reference_v<T=
>>>
void gut(T&& t)
{
// What code could I put here that makes any sense?
// It would have to be code that *doesn't* work with lvalues,
// yet *does* work with *any arbitrary* type T.
}
Can you help fill in the blanks?
HTH,
=E2=80=93Arthur
--=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/CADvuK0LEzbtzfx9wTg7i9xGUzua1n-jJZYSbNOxpS-K5tyZ=
erg%40mail.gmail.com.
--94eb2c07654cb2d3ee05498b3bdc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 27, 2017 at 12:39 PM, Denis Kotov <span dir=3D=
"ltr"><<a href=3D"mailto:redradist@gmail.com" target=3D"_blank">redradis=
t@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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr">Thanks you for answer, A=
rthur<div><br></div><div>I have seen your video and understand reference co=
llapsing.</div><div><br></div><div>In this case I have two questions:</div>=
<div>1) But do not you think it is confusing ?</div></div></blockquote><div=
><br></div><div>I think it's as "confusing" as e.g. the fact =
that we have two versions of operator++ (one taking no arguments and the ot=
her taking "int"), or that the rules for template type deduction =
are different between function templates and class templates (even in C++17=
). That is,none of these are things you're likely to work out from firs=
t principles yourself. But once it's explained to you =C2=A0once, it=
9;s easy to remember and apply the rule in a variety of everyday situations=
..</div><div><br></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);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>2) Do not you =
think if I have tempate like this:</div><div><br></div><div>=C2=A0 =C2=A0 t=
emplate<typename T></div><div>=C2=A0 =C2=A0 void run(T && t)<=
/div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 // I want to be su=
re that t is rvalue and I can catch all data that are stored in it because =
anyway it will be deleted after this function</div><div>=C2=A0 =C2=A0 }</di=
v><div><br></div><div><div>=C2=A0 =C2=A0 template<typename T></div><d=
iv>=C2=A0 =C2=A0 void run(T & t)</div><div>=C2=A0 =C2=A0 {</div><div>=
=C2=A0 =C2=A0 =C2=A0 // I know exactly that t is lvalue and I cannot do not=
hing bad with data of this structure</div><div>=C2=A0 =C2=A0 }</div></div><=
/div></blockquote><div><br></div><div>Wrong.=C2=A0<a href=3D"http://melpon.=
org/wandbox/permlink/Uw1UnuCVJgk2ppvh">http://melpon.org/wandbox/permlink/U=
w1UnuCVJgk2ppvh</a><br></div><div><br></div><div>Be careful with your termi=
nology here. Your comments are currently wrong. What you should say is</div=
><div><br></div><div><font face=3D"monospace, monospace">template<typena=
me T> void run(T&& t)</font></div><div><font face=3D"monospace, =
monospace">{</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 // As far as my caller is concerned, I promise not to hold onto a re=
ference to t</font></div><div><font face=3D"monospace, monospace">}</font><=
/div><div><font face=3D"monospace, monospace"><br></font></div><div><div><f=
ont face=3D"monospace, monospace">template<typename T> void run(T&=
; t)</font></div><div><font face=3D"monospace, monospace">{</font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // As far as my caller =
is concerned, I require the ability to hold onto a reference to t</font></d=
iv><div><font face=3D"monospace, monospace">}</font></div></div><div><br></=
div><div>Therefore it is legitimate to pass rvalues to <font face=3D"monosp=
ace, monospace">run(T&&)</font>, but it is not legitimate to pass r=
values to <font face=3D"monospace, monospace">run(T&)</font> (because i=
f the caller believes that he's holding an rvalue, there's no way f=
or the caller to satisfy <font face=3D"monospace, monospace">run(T&)</f=
ont>'s request for an lvalue).</div><div><br></div><div><br></div><bloc=
kquote 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;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div>3) If you anyway think that forwardi=
ng reference is useful, can you give an example of usefulness ?<br></div></=
div></div></blockquote><div><br></div><div>std::invoke. std::forward. std::=
forward_as_tuple. std::make_tuple. std::make_unique. std::make_shared. std:=
:vector::emplace. std::map::emplace. Basically, any function or constructor=
that you can currently imagine passing <font face=3D"monospace, monospace"=
>std::move(x)</font> to, or any function or constructor whose semantics are=
defined in terms of "perfect forwarding".</div><div><br></div><d=
iv>When you ask for the abolition of perfect forwarding, you're basical=
ly asking for the abolition of C++11 rvalue semantics; this is why your req=
uest isn't getting a whole lot of traction.</div><div><br></div><div>By=
the way, if you want to ensure that a certain function accepts nothing but=
rvalues from its caller, I believe you could write</div><div><br></div><di=
v><div><font face=3D"monospace, monospace">template<typename T, typename=
E =3D std::enable_if_t<!std::is_reference_v<T>>></font></di=
v><div><font face=3D"monospace, monospace">void run(T&& t)</font></=
div><div><font face=3D"monospace, monospace">{</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 // As far as my caller is concerned=
, I promise not to hold onto a reference to t...</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0 // and I also REQUIRE that my CALL=
ER not hold onto such a reference either!</font></div><div><font face=3D"mo=
nospace, monospace">}</font></div></div><div><font face=3D"monospace, monos=
pace"><br></font></div><div>But I find it hard to imagine a case where this=
behavior would actually be useful. The only reason to accept specifically =
an rvalue is because you plan to disembowel the rvalue and use its guts for=
something else. Under the current rules, disemboweling-or-not happens natu=
rally and appropriately due to copy/move semantics and perfect forwarding. =
You're wanting to write a function that <i>unconditionally disembowels<=
/i> its argument, and then asking for a way to make that "safe". =
I'm saying that unconditionally disemboweling things is not the C++ way=
.. Besides, how would you even know how to gut an object if you didn't k=
now its type?</div><div><br></div><div><div><font face=3D"monospace, monosp=
ace">template<typename T, typename E =3D std::enable_if_t<!std::is_re=
ference_v<T>>></font></div><div><font face=3D"monospace, monosp=
ace">void gut(T&& t)</font></div><div><font face=3D"monospace, mono=
space">{</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
// What code could I put here that makes any sense?</font></div><div><font=
face=3D"monospace, monospace">=C2=A0 =C2=A0 // It would have to be code th=
at <i>doesn't</i> work with lvalues,</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 // yet <i>does</i> work with <i>any arbitr=
ary</i> type T.</font></div><div><span style=3D"font-family:monospace,monos=
pace">}</span><br></div></div><div><br></div><div>Can you help fill in the =
blanks?</div><div><br></div><div>HTH,</div><div>=E2=80=93Arthur</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/CADvuK0LEzbtzfx9wTg7i9xGUzua1n-jJZYSb=
NOxpS-K5tyZerg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LEzbtzfx9w=
Tg7i9xGUzua1n-jJZYSbNOxpS-K5tyZerg%40mail.gmail.com</a>.<br />
--94eb2c07654cb2d3ee05498b3bdc--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 27 Feb 2017 16:32:45 -0800 (PST)
Raw View
------=_Part_2301_1104877832.1488241965212
Content-Type: multipart/alternative;
boundary="----=_Part_2302_2132747203.1488241965212"
------=_Part_2302_2132747203.1488241965212
Content-Type: text/plain; charset=UTF-8
On Monday, February 27, 2017 at 3:39:16 PM UTC-5, Denis Kotov wrote:
>
> 3) If you anyway think that forwarding reference is useful, can you give
> an example of usefulness ?
>
.... oh, now I get what the problem is.
It now seems apparent that you are under the impression that forwarding
references are some kind of accident. That nobody really thought about the
reference collapsing and template argument deduction of rvalues. That
forwarding references were something effect that came out of the natural
growth of rvalue references and template deduction.
Forwarding references didn't happen by accident; the specific reference
collapsing rules that led to forwarding references were added *deliberately
and purposefully* to C++0x's rvalue reference system (which in its original
form didn't behave like this). They were added to solve a specific and
pernicious problem. Namely the forwarding problem, which is why these rules
(and `std::forward`) are often collectively referred to as "perfect
forwarding". Proper use of forwarding references solves the forwarding
problem, thus allowing *numerous* C++ functions to exist and do their jobs
correctly and without creating unnecessary copies or inhibiting moves.
If you want to understand the forwarding problem in detail, read the paper
that introduced these reference collapsing rules to C++
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm>. But
until you understand the purpose that forwarding references *currently
serve*, we cannot effectively discuss whether or not it is reasonable to
remove them.
In order to remove forwarding references, you would need to re-solve the
forwarding problem. Because we're not going to give up our only solution to
that just because it confuses you.
Also, please stop top-posting.
--
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/fb147f1a-a9c1-4a7e-b783-e91ee51d5532%40isocpp.org.
------=_Part_2302_2132747203.1488241965212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 27, 2017 at 3:39:16 PM UTC-5, Denis Ko=
tov 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">3) =
If you anyway think that forwarding reference is useful, can you give an ex=
ample of usefulness ?</div></blockquote><div><br>... oh, now I get what the=
problem is.<br><br>It now seems apparent that you are under the impression=
that forwarding references are some kind of accident. That nobody really t=
hought about the reference collapsing and template argument deduction of rv=
alues. That forwarding references were something effect that came out of th=
e natural growth of rvalue references and template deduction.<br><br>Forwar=
ding references didn't happen by accident; the specific reference colla=
psing rules that led to forwarding references were added <i>deliberately an=
d purposefully</i>
to C++0x's rvalue reference system (which in its original form didn=
9;t=20
behave like this). They were added to solve a specific and pernicious=20
problem. Namely the forwarding problem, which is why these rules (and=20
`std::forward`) are often collectively referred to as "perfect forward=
ing". Proper use
of forwarding references solves the forwarding problem, thus allowing <i>n=
umerous</i> C++ functions to exist and do their jobs correctly and without =
creating unnecessary copies or inhibiting moves.<br><br>If you want to unde=
rstand the forwarding problem in detail, read <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm">the paper that introduced =
these reference collapsing rules to C++</a>. But until you understand the p=
urpose that forwarding references <i>currently serve</i>, we cannot effecti=
vely discuss whether or not it is reasonable to remove them.<br><br>In orde=
r to remove forwarding references, you would need to re-solve the forwardin=
g problem. Because we're not going to give up our only solution to that=
just because it confuses you.</div><br>Also, please stop top-posting.<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/fb147f1a-a9c1-4a7e-b783-e91ee51d5532%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb147f1a-a9c1-4a7e-b783-e91ee51d5532=
%40isocpp.org</a>.<br />
------=_Part_2302_2132747203.1488241965212--
------=_Part_2301_1104877832.1488241965212--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 27 Feb 2017 22:41:10 -0800
Raw View
Em segunda-feira, 27 de fevereiro de 2017, =C3=A0s 11:45:31 PST, Denis Koto=
v=20
escreveu:
> But it is right now time to fix it.
Ok, then make your proposal on what the non-broken way of implementing perf=
ect=20
forwarding would be.
--=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/7297869.gZmkp0n7eH%40tjmaciei-mobl1.
.
Author: TONGARI J <tongari95@gmail.com>
Date: Mon, 27 Feb 2017 23:38:25 -0800 (PST)
Raw View
------=_Part_4109_2124692242.1488267505437
Content-Type: multipart/alternative;
boundary="----=_Part_4110_1300454135.1488267505437"
------=_Part_4110_1300454135.1488267505437
Content-Type: text/plain; charset=UTF-8
Hi Denis,
I believe the solution below serves your need well.
template<class T, std::enable_if_t<!std::is_reference<T>::value, bool> =
true>
using rval = T;
template<class T>
void f(rval<T>&&)
{
std::cout << "rvalue_reference\n";
}
template<class T>
void f(T&)
{
std::cout << "lvalue_reference\n";
}
Live demo: http://melpon.org/wandbox/permlink/1SvJVZ8OdFET2qPb
You can use rval<T> when you want to ensure T is a value type, not a
reference thing.
--
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/24056019-259b-49cd-b868-871738502e24%40isocpp.org.
------=_Part_4110_1300454135.1488267505437
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Denis,<div><br></div><div>I believe the solution below =
serves your need well.</div><div><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">enable_if_t</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><!</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">is_reference</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">>::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">true</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> rval </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>rval</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">>&&)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"rvalue_reference\n"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"lvalue_reference\n"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span></div></code></div><div>Live demo: http://melpo=
n.org/wandbox/permlink/1SvJVZ8OdFET2qPb</div></div><div><br></div><div>You =
can use=C2=A0<span class=3D"styled-by-prettify" style=3D"font-family: monos=
pace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">rval</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: monospace; backg=
round-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"><</span><span=
class=3D"styled-by-prettify" style=3D"font-family: monospace; background-c=
olor: rgb(250, 250, 250); color: rgb(0, 0, 0);">T</span><span class=3D"styl=
ed-by-prettify" style=3D"font-family: monospace; background-color: rgb(250,=
250, 250); color: rgb(102, 102, 0);">></span>=C2=A0when you want to ens=
ure T is a value type, not a reference thing.</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/24056019-259b-49cd-b868-871738502e24%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24056019-259b-49cd-b868-871738502e24=
%40isocpp.org</a>.<br />
------=_Part_4110_1300454135.1488267505437--
------=_Part_4109_2124692242.1488267505437--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Tue, 28 Feb 2017 13:24:49 -0800 (PST)
Raw View
------=_Part_880_1560263533.1488317089160
Content-Type: multipart/alternative;
boundary="----=_Part_881_535413334.1488317089160"
------=_Part_881_535413334.1488317089160
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi TONGARI J,
Thanks for very useful example !!!!
Your solution fixes the issue very elegantly and at the same case we have=
=20
extensible function that can take all available arguments.
Maybe I was a bit wrong.
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 28 =D1=84=D0=B5=D0=B2=D1=80=D0=
=B0=D0=BB=D1=8F 2017 =D0=B3., 9:38:25 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C TONGARI J =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
>
> Hi Denis,
>
> I believe the solution below serves your need well.
> template<class T, std::enable_if_t<!std::is_reference<T>::value, bool> =
=3D=20
> true>
> using rval =3D T;
>
> template<class T>
> void f(rval<T>&&)
> {
> std::cout << "rvalue_reference\n";
> }
>
> template<class T>
> void f(T&)
> {
> std::cout << "lvalue_reference\n";
> }
> Live demo: http://melpon.org/wandbox/permlink/1SvJVZ8OdFET2qPb
>
> You can use rval<T> when you want to ensure T is a value type, not a=20
> reference thing.
>
--=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/40492ec6-e04a-4db0-a72d-243c4ca9896e%40isocpp.or=
g.
------=_Part_881_535413334.1488317089160
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi=C2=A0<span class=3D"_username" style=3D"white-space: no=
wrap;"><span class=3D"IVILX2C-D-a">TONGARI J,</span></span><div><span style=
=3D"white-space: nowrap;"><b><br></b></span></div><div><div><span style=3D"=
white-space: nowrap;">Thanks for very useful example !!!!</span></div><div>=
<span style=3D"white-space: nowrap;">Your solution fixes the issue very ele=
gantly and at the same case we have extensible function that can take all a=
vailable arguments.</span></div></div><div><span style=3D"white-space: nowr=
ap;"><br></span></div><div><span style=3D"white-space: nowrap;">Maybe I was=
a bit wrong.</span></div><div><br>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=
=BA, 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2017 =D0=B3., 9:38:25 UT=
C+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C TONGARI J =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Hi Denis,<div><br></div><div>I=
believe the solution below serves your need well.</div><div><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"co=
lor:#008">template</span><span style=3D"color:#660"><</span><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> T</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">enable_if_t</span><span=
style=3D"color:#660"><!</span><span style=3D"color:#000">std</span><spa=
n style=3D"color:#660">::</span><span style=3D"color:#000">is_<wbr>referenc=
e</span><span style=3D"color:#660"><</span><span style=3D"color:#000">T<=
/span><span style=3D"color:#660">>::</span><span style=3D"color:#000">va=
lue</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">bool</span><span style=3D"color:#660">><=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">true</span=
><span style=3D"color:#660">></span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#008">using</span><span style=3D"color:#000"> rval <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br><=
/span><span style=3D"color:#008">template</span><span style=3D"color:#660">=
<</span><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> T</span><span style=3D"color:#660">></span><span style=3D"color:#000"=
><br></span><span style=3D"color:#008">void</span><span style=3D"color:#000=
"> f</span><span style=3D"color:#660">(</span><span style=3D"color:#000">rv=
al</span><span style=3D"color:#660"><</span><span style=3D"color:#000">T=
</span><span style=3D"color:#660">>&&)</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span=
style=3D"color:#000">cout </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> </span><span style=3D"color:#080">"rvalue=
_reference\n"</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br><br></span><span style=3D"color:#008">template</span><span st=
yle=3D"color:#660"><</span><span style=3D"color:#008">class</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span =
style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">T</span><span style=3D"color:#660">&)</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</=
span><span style=3D"color:#000">cout </span><span style=3D"color:#660"><=
<</span><span style=3D"color:#000"> </span><span style=3D"color:#080">&q=
uot;lvalue_reference\n"</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div><=
/code></div><div>Live demo: <a href=3D"http://melpon.org/wandbox/permlink/1=
SvJVZ8OdFET2qPb" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2=
Fpermlink%2F1SvJVZ8OdFET2qPb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH3Vmen=
KmuSunWXU7h94yq9SLTBhw';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2F1S=
vJVZ8OdFET2qPb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH3VmenKmuSunWXU7h94y=
q9SLTBhw';return true;">http://melpon.org/wandbox/<wbr>permlink/1SvJVZ8=
OdFET2qPb</a></div></div><div><br></div><div>You can use=C2=A0<span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,0=
)">rval</span><span style=3D"font-family:monospace;background-color:rgb(250=
,250,250);color:rgb(102,102,0)"><</span><span style=3D"font-family:monos=
pace;background-color:rgb(250,250,250);color:rgb(0,0,0)">T</span><span styl=
e=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,=
102,0)">></span>=C2=A0when you want to ensure T is a value type, not a r=
eference thing.</div></div></blockquote></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/40492ec6-e04a-4db0-a72d-243c4ca9896e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40492ec6-e04a-4db0-a72d-243c4ca9896e=
%40isocpp.org</a>.<br />
------=_Part_881_535413334.1488317089160--
------=_Part_880_1560263533.1488317089160--
.