Topic: P0756R0: "Lambda syntax should be more liberal in
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 17 Jul 2017 11:46:37 -0700 (PDT)
Raw View
------=_Part_255_1273676848.1500317197905
Content-Type: multipart/alternative;
boundary="----=_Part_256_271331324.1500317197905"
------=_Part_256_271331324.1500317197905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
> This paper proposes to remove two minor stumbling blocks to the=20
> teachability of lambda syntax =E2=80=94 stumbling blocks of which many pr=
ogrammers=20
> may not even be aware.
> The first is that [&x, =3D](){ return x; } is ill-formed.
> The second is that [=3D, y](){ return x; } is ill-formed.
> I propose to make both of these lambdas well-formed, with the obvious=20
> meanings.
http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
Comments welcome, either here or via email. Remember to read the paper=20
first, though!
=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/6583614e-2450-43dc-8dd0-638d620127e3%40isocpp.or=
g.
------=_Part_256_271331324.1500317197905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;"><span style=3D"color: rgb(0, 0, 0); font-famil=
y: -webkit-standard; font-size: medium;">This paper proposes to remove two =
minor stumbling blocks to the teachability of lambda syntax =E2=80=94 stumb=
ling blocks of which many programmers may not even be aware.<br></span><spa=
n style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: m=
edium;">The first is that=C2=A0</span><code style=3D"color: rgb(0, 0, 0);">=
[&x, =3D](){ return x; }</code><span style=3D"color: rgb(0, 0, 0); font=
-family: -webkit-standard; font-size: medium;">=C2=A0is ill-formed.<br></sp=
an><span style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard; font-=
size: medium;">The second is that=C2=A0</span><code style=3D"color: rgb(0, =
0, 0);">[=3D, y](){ return x; }</code><span style=3D"color: rgb(0, 0, 0); f=
ont-family: -webkit-standard; font-size: medium;">=C2=A0is ill-formed.<br><=
/span><span style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard; fo=
nt-size: medium;">I propose to make both of these lambdas well-formed, with=
the obvious meanings.</span></blockquote><div><br></div><a href=3D"http://=
quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html">http://quuxplu=
sone.github.io/draft/liberal-syntax-for-lambdas.html</a><br><div><br></div>=
<div>Comments welcome, either here or via email. Remember to read the paper=
first, though!</div><div><br></div><div>=E2=80=93Arthur</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/6583614e-2450-43dc-8dd0-638d620127e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6583614e-2450-43dc-8dd0-638d620127e3=
%40isocpp.org</a>.<br />
------=_Part_256_271331324.1500317197905--
------=_Part_255_1273676848.1500317197905--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 17 Jul 2017 16:00:00 -0700 (PDT)
Raw View
------=_Part_1730_35353182.1500332400694
Content-Type: multipart/alternative;
boundary="----=_Part_1731_841577722.1500332400694"
------=_Part_1731_841577722.1500332400694
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, July 17, 2017 at 2:46:38 PM UTC-4, Arthur O'Dwyer wrote:
>
> This paper proposes to remove two minor stumbling blocks to the=20
>> teachability of lambda syntax =E2=80=94 stumbling blocks of which many p=
rogrammers=20
>> may not even be aware.
>> The first is that [&x, =3D](){ return x; } is ill-formed.
>> The second is that [=3D, y](){ return x; } is ill-formed.
>> I propose to make both of these lambdas well-formed, with the obvious=20
>> meanings.
>
>
> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
>
> Comments welcome, either here or via email. Remember to read the paper=20
> first, though!
>
>
> placing the =3D at the end of the list (where it logically belongs)
I strongly disagree with the parenthetical statement. Seeing `=3D` first=20
makes it clear to the reader that this is a value default-capturing lambda.=
=20
Seeing `&` first makes it clear that it's a reference default-capturing=20
lambda. Seeing neither makes it clear that it captures only what is listed.
It's a simple rule to remember: put the default *first*. I don't think that=
=20
rule affects teachability.
The reason why you needed that paragraph is because you *taught it wrong*.=
=20
Your tutorial said "To capture "everything needed by this lambda, and=20
nothing else," simply add a single =3D to your capture-list (to capture by=
=20
value), or add a single & (to capture by reference)." That's incorrect. The=
=20
correct phrase is "To capture "everything needed by this lambda, and=20
nothing else, *simply put =3D (to capture by value), or & (to capture by=20
reference) at the beginning of your capture list.*"
Your mistake is not the standard's fault.
As for making redundancy illegal, I believe that if you write something=20
redundant, then you've clearly made some kind of mistake. If you use a=20
default capture, and you then capture a variable in the same way as the=20
default capture, then you are perhaps confused as to what you meant to=20
capture and how you meant to capture it.
Yes, you can now use capture expressions to get the same effect without=20
getting an error. But I don't think that represents a problem.
> improve our friendliness to machine-generated or mechanically-refactored=
=20
code.
OK, this is a much better point for the forbidding redundancy issue. Even=
=20
so, I'd like to know a bit more about why the machine generated code would=
=20
think that it needs to value-capture everything, while another part of the=
=20
machine generated code needs to value capture a specific variable. These=20
two thoughts don't seem to be in sync; it seems more likely that we'd be in=
=20
a world where the user (the one providing some of the code that goes in the=
=20
lambda) specified either the default capture or the specific variable=20
capture, and the machine system specified the other.
But that still doesn't justify allowing default-capture after the start of=
=20
a lambda.
--=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/3412e378-046a-4164-b3dc-755f62c2dc2a%40isocpp.or=
g.
------=_Part_1731_841577722.1500332400694
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 17, 2017 at 2:46:38 PM UTC-4, Arth=
ur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span style=3D"color:rgb(0,0,0);font-family:-webkit-standard;font-s=
ize:medium">This paper proposes to remove two minor stumbling blocks to the=
teachability of lambda syntax =E2=80=94 stumbling blocks of which many pro=
grammers may not even be aware.<br></span><span style=3D"color:rgb(0,0,0);f=
ont-family:-webkit-standard;font-size:medium">The first is that=C2=A0</span=
><code style=3D"color:rgb(0,0,0)">[&x, =3D](){ return x; }</code><span =
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">=
=C2=A0is ill-formed.<br></span><span style=3D"color:rgb(0,0,0);font-family:=
-webkit-standard;font-size:medium">The second is that=C2=A0</span><code sty=
le=3D"color:rgb(0,0,0)">[=3D, y](){ return x; }</code><span style=3D"color:=
rgb(0,0,0);font-family:-webkit-standard;font-size:medium">=C2=A0is ill-form=
ed.<br></span><span style=3D"color:rgb(0,0,0);font-family:-webkit-standard;=
font-size:medium">I propose to make both of these lambdas well-formed, with=
the obvious meanings.</span></blockquote><div><br></div><a href=3D"http://=
quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fquuxplusone.github.io%2Fdraft%2Fliberal-syntax-for-la=
mbdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeW=
VQfA';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fquuxplusone.github.io%2Fdraft%2Fliberal-syntax-for-lam=
bdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeWV=
QfA';return true;">http://quuxplusone.github.io/<wbr>draft/liberal-synt=
ax-for-<wbr>lambdas.html</a><br><div><br></div><div>Comments welcome, eithe=
r here or via email. Remember to read the paper first, though!</div><br></b=
lockquote><div><br>> placing the =3D at the end of the list (where it lo=
gically belongs)<br><br>I strongly disagree with the parenthetical statemen=
t. Seeing `=3D` first makes it clear to the reader that this is a value def=
ault-capturing lambda. Seeing `&` first makes it clear that it's a =
reference default-capturing lambda. Seeing neither makes it clear that it c=
aptures only what is listed.<br><br>It's a simple rule to remember: put=
the default <i>first</i>. I don't think that rule affects teachability=
..<br><br>The reason why you needed that paragraph is because you <i>taught =
it wrong</i>. Your tutorial said "To capture "everything needed b=
y this lambda, and nothing else," simply add a single =3D to your capt=
ure-list (to capture by value), or add a single & (to capture by refere=
nce)." That's incorrect. The correct phrase is "To capture &q=
uot;everything needed by this lambda, and nothing else, <u>simply put =3D (=
to capture by value), or <code>&</code> (to capture by reference) at th=
e beginning of your capture list.</u>"<br><br>Your mistake is not the =
standard's fault.<br><br>As for making redundancy illegal, I believe th=
at if you write something redundant, then you've clearly made some kind=
of mistake. If you use a default capture, and you then capture a variable =
in the same way as the default capture, then you are perhaps confused as to=
what you meant to capture and how you meant to capture it.<br><br>Yes, you=
can now use capture expressions to get the same effect without getting an =
error. But I don't think that represents a problem.<br><br>> improve=
our friendliness to machine-generated or mechanically-refactored code.<br>=
<br>OK, this is a much better point for the forbidding redundancy issue. Ev=
en so, I'd like to know a bit more about why the machine generated code=
would think that it needs to value-capture everything, while another part =
of the machine generated code needs to value capture a specific variable. T=
hese two thoughts don't seem to be in sync; it seems more likely that w=
e'd be in a world where the user (the one providing some of the code th=
at goes in the lambda) specified either the default capture or the specific=
variable capture, and the machine system specified the other.<br><br>But t=
hat still doesn't justify allowing default-capture after the start of a=
lambda.<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/3412e378-046a-4164-b3dc-755f62c2dc2a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3412e378-046a-4164-b3dc-755f62c2dc2a=
%40isocpp.org</a>.<br />
------=_Part_1731_841577722.1500332400694--
------=_Part_1730_35353182.1500332400694--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 18 Jul 2017 09:19:37 -0700 (PDT)
Raw View
------=_Part_2211_1047169894.1500394777582
Content-Type: multipart/alternative;
boundary="----=_Part_2212_32488582.1500394777583"
------=_Part_2212_32488582.1500394777583
Content-Type: text/plain; charset="UTF-8"
>
> As for making redundancy illegal, I believe that if you write something
> redundant, then you've clearly made some kind of mistake. If you use a
> default capture, and you then capture a variable in the same way as the
> default capture, then you are perhaps confused as to what you meant to
> capture and how you meant to capture it.
>
>
I think the problem OP is trying to solve is that he wants to capture a
variable by-copy that isn't actually odr-used (or really, used by any
definition) in the lambda. So [=] won't capture it, but [=, token] is
ill-formed.
--
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/442ffa76-11fc-4fec-bf8e-c063a0459ac2%40isocpp.org.
------=_Part_2212_32488582.1500394777583
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>As for making redundancy illegal, I believe that if you write some=
thing redundant, then you've clearly made some kind of mistake. If you =
use a default capture, and you then capture a variable in the same way as t=
he default capture, then you are perhaps confused as to what you meant to c=
apture and how you meant to capture it.<br><br></div></div></blockquote><di=
v><br></div><div>I think the problem OP is trying to solve is that he wants=
to capture a variable by-copy that isn't actually odr-used (or really,=
used by any definition) in the lambda. So [=3D] won't capture it, but =
[=3D, token] is ill-formed.=C2=A0</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/442ffa76-11fc-4fec-bf8e-c063a0459ac2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/442ffa76-11fc-4fec-bf8e-c063a0459ac2=
%40isocpp.org</a>.<br />
------=_Part_2212_32488582.1500394777583--
------=_Part_2211_1047169894.1500394777582--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 18 Jul 2017 10:01:35 -0700 (PDT)
Raw View
------=_Part_2277_1133097543.1500397295491
Content-Type: multipart/alternative;
boundary="----=_Part_2278_2106820971.1500397295491"
------=_Part_2278_2106820971.1500397295491
Content-Type: text/plain; charset="UTF-8"
On Tuesday, July 18, 2017 at 12:19:37 PM UTC-4, Barry Revzin wrote:
>
> As for making redundancy illegal, I believe that if you write something
>> redundant, then you've clearly made some kind of mistake. If you use a
>> default capture, and you then capture a variable in the same way as the
>> default capture, then you are perhaps confused as to what you meant to
>> capture and how you meant to capture it.
>>
>>
> I think the problem OP is trying to solve is that he wants to capture a
> variable by-copy that isn't actually odr-used (or really, used by any
> definition) in the lambda. So [=] won't capture it, but [=, token] is
> ill-formed.
>
In that case, I think the `x=x` form would make it more clear what you're
trying to do. It demonstrates that you're not merely capturing the variable
for use in the lambda; you're explicitly and deliberately copying it into
the members of the object.
--
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/6faee3d3-c3e6-4c64-ba44-f22539fe5c6d%40isocpp.org.
------=_Part_2278_2106820971.1500397295491
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 18, 2017 at 12:19:37 PM UTC-4, Barry Revz=
in 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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>As for making red=
undancy illegal, I believe that if you write something redundant, then you&=
#39;ve clearly made some kind of mistake. If you use a default capture, and=
you then capture a variable in the same way as the default capture, then y=
ou are perhaps confused as to what you meant to capture and how you meant t=
o capture it.<br><br></div></div></blockquote><div><br></div><div>I think t=
he problem OP is trying to solve is that he wants to capture a variable by-=
copy that isn't actually odr-used (or really, used by any definition) i=
n the lambda. So [=3D] won't capture it, but [=3D, token] is ill-formed=
..</div></div></blockquote><div><br>In that case, I think the `x=3Dx` form w=
ould make it more clear what you're trying to do. It demonstrates that =
you're not merely capturing the variable for use in the lambda; you'=
;re explicitly and deliberately copying it into the members of the object.<=
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/6faee3d3-c3e6-4c64-ba44-f22539fe5c6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6faee3d3-c3e6-4c64-ba44-f22539fe5c6d=
%40isocpp.org</a>.<br />
------=_Part_2278_2106820971.1500397295491--
------=_Part_2277_1133097543.1500397295491--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Tue, 15 Aug 2017 21:29:17 +0300
Raw View
This is a multi-part message in MIME format.
--------------698BBA69B87D463EC44B9D38
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:
>
> This paper proposes to remove two minor stumbling blocks to the
> teachability of lambda syntax =E2=80=94 stumbling blocks of which man=
y
> programmers may not even be aware.
> The first is that |[&x, =3D](){ return x; }| is ill-formed.
> The second is that |[=3D, y](){ return x; }| is ill-formed.
> I propose to make both of these lambdas well-formed, with the
> obvious meanings.
>
>
> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
>
> Comments welcome, either here or via email. Remember to read the paper=20
> first, though!
>
I would like to re-raise [&&x] as a shortcut for [x =3D std::move(x)] ()=20
mutable. It is seen extensively in continuation passing code, and since=20
the language has first-class support for moves, lambdas should too.
--=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/40ba73f0-cbb4-ddb5-7a4e-530683fd7200%40scylladb.=
com.
--------------698BBA69B87D463EC44B9D38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 07/17/2017 09:46 PM, Arthur O'Dwyer
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:6583614e-2450-43dc-8dd0-638d620127e3@isocpp.org">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;
border-left-width: 1px; border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;"><span
style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard;
font-size: medium;">This paper proposes to remove two minor
stumbling blocks to the teachability of lambda syntax =E2=80=94
stumbling blocks of which many programmers may not even be
aware.<br>
</span><span style=3D"color: rgb(0, 0, 0); font-family:
-webkit-standard; font-size: medium;">The first is that=C2=A0</sp=
an><code
style=3D"color: rgb(0, 0, 0);">[&x, =3D](){ return x; }</code=
><span
style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard;
font-size: medium;">=C2=A0is ill-formed.<br>
</span><span style=3D"color: rgb(0, 0, 0); font-family:
-webkit-standard; font-size: medium;">The second is that=C2=A0</s=
pan><code
style=3D"color: rgb(0, 0, 0);">[=3D, y](){ return x; }</code><spa=
n
style=3D"color: rgb(0, 0, 0); font-family: -webkit-standard;
font-size: medium;">=C2=A0is ill-formed.<br>
</span><span style=3D"color: rgb(0, 0, 0); font-family:
-webkit-standard; font-size: medium;">I propose to make both
of these lambdas well-formed, with the obvious meanings.</span></=
blockquote>
<div><br>
</div>
<a
href=3D"http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html"
moz-do-not-send=3D"true">http://quuxplusone.github.io/draft/liberal=
-syntax-for-lambdas.html</a><br>
<div><br>
</div>
<div>Comments welcome, either here or via email. Remember to read
the paper first, though!</div>
<div><br>
</div>
</blockquote>
<br>
I would like to re-raise [&&x] as a shortcut for [x =3D
std::move(x)] () mutable.=C2=A0 It is seen extensively in continuation
passing code, and since the language has first-class support for
moves, lambdas should too.<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/40ba73f0-cbb4-ddb5-7a4e-530683fd7200%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/40ba73f0-cbb4-ddb5-7a4e-530683fd72=
00%40scylladb.com</a>.<br />
--------------698BBA69B87D463EC44B9D38--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 15 Aug 2017 12:03:32 -0700 (PDT)
Raw View
------=_Part_6685_1535638006.1502823812574
Content-Type: multipart/alternative;
boundary="----=_Part_6686_845437404.1502823812574"
------=_Part_6686_845437404.1502823812574
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>
> On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:
>
> This paper proposes to remove two minor stumbling blocks to the=20
>> teachability of lambda syntax =E2=80=94 stumbling blocks of which many p=
rogrammers=20
>> may not even be aware.
>> The first is that [&x, =3D](){ return x; } is ill-formed.
>> The second is that [=3D, y](){ return x; } is ill-formed.
>> I propose to make both of these lambdas well-formed, with the obvious=20
>> meanings.
>
>
> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
>
> Comments welcome, either here or via email. Remember to read the paper=20
> first, though!
>
>
> I would like to re-raise [&&x] as a shortcut for [x =3D std::move(x)] ()=
=20
> mutable. It is seen extensively in continuation passing code, and since=
=20
> the language has first-class support for moves, lambdas should too.
>
One could argue for the `&&x -> x =3D std::move(x)` part. But the automatic=
=20
`mutable`-izing part? No. Whether you agree with the `const`-by-default=20
nature of lambdas or not, we shouldn't create syntax that arbitrarily=20
changes the nature of a lambda.=20
Also, do you really want to move from `x`? Or do you want to do a=20
decay-copy into `x`? Because the latter is what `std::thread/async` do. And=
=20
we already have a proposal for shortening that <http://wg21.link/P0644>.
--=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/77a437cb-0cb3-4abb-a350-5dc72827073c%40isocpp.or=
g.
------=_Part_6686_845437404.1502823812574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivit=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 07/17/2017 09:46 PM, Arthur O'Dwyer
wrote:<br>
</div>
<blockquote type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><span style=3D"color:rgb(0,0,0);font-family:-webkit-=
standard;font-size:medium">This paper proposes to remove two minor
stumbling blocks to the teachability of lambda syntax =E2=80=94
stumbling blocks of which many programmers may not even be
aware.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-standard=
;font-size:medium">The first is that=C2=A0</span><code style=3D"color:rgb(0=
,0,0)">[&x, =3D](){ return x; }</code><span style=3D"color:rgb(0,0,0);f=
ont-family:-webkit-standard;font-size:medium">=C2=A0is ill-formed.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-standard=
;font-size:medium">The second is that=C2=A0</span><code style=3D"color:rgb(=
0,0,0)">[=3D, y](){ return x; }</code><span style=3D"color:rgb(0,0,0);font-=
family:-webkit-standard;font-size:medium">=C2=A0is ill-formed.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-standard=
;font-size:medium">I propose to make both
of these lambdas well-formed, with the obvious meanings.</span></=
blockquote>
<div><br>
</div>
<a href=3D"http://quuxplusone.github.io/draft/liberal-syntax-for-lamb=
das.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplusone.github.io%2Fdraft=
%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
Fei46vIflA1T7IvOrTxWoyeWVQfA';return true;" onclick=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplusone.github.io%2Fdraft%=
2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
ei46vIflA1T7IvOrTxWoyeWVQfA';return true;">http://quuxplusone.github.io=
/<wbr>draft/liberal-syntax-for-<wbr>lambdas.html</a><br>
<div><br>
</div>
<div>Comments welcome, either here or via email. Remember to read
the paper first, though!</div>
<div><br>
</div>
</blockquote>
<br>
I would like to re-raise [&&x] as a shortcut for [x =3D
std::move(x)] () mutable.=C2=A0 It is seen extensively in continuation
passing code, and since the language has first-class support for
moves, lambdas should too.<br></div></blockquote><div><br>One could arg=
ue for the `&&x -> x =3D std::move(x)` part. But the automatic `=
mutable`-izing part? No. Whether you agree with the `const`-by-default natu=
re of lambdas or not, we shouldn't create syntax that arbitrarily chang=
es the nature of a lambda. <br><br>Also, do you really want to move from `x=
`? Or do you want to do a decay-copy into `x`? Because the latter is what `=
std::thread/async` do. And we <a href=3D"http://wg21.link/P0644">already ha=
ve a proposal for shortening that</a>.<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/77a437cb-0cb3-4abb-a350-5dc72827073c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77a437cb-0cb3-4abb-a350-5dc72827073c=
%40isocpp.org</a>.<br />
------=_Part_6686_845437404.1502823812574--
------=_Part_6685_1535638006.1502823812574--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 16 Aug 2017 11:47:27 +0300
Raw View
This is a multi-part message in MIME format.
--------------35C4E91320960B8F13AB1739
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 08/15/2017 10:03 PM, Nicol Bolas wrote:
> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>
> On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:
>>
>> This paper proposes to remove two minor stumbling blocks to
>> the teachability of lambda syntax =E2=80=94 stumbling blocks of =
which
>> many programmers may not even be aware.
>> The first is that |[&x, =3D](){ return x; }| is ill-formed.
>> The second is that |[=3D, y](){ return x; }| is ill-formed.
>> I propose to make both of these lambdas well-formed, with the
>> obvious meanings.
>>
>>
>> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
>> <http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html>
>>
>> Comments welcome, either here or via email. Remember to read the
>> paper first, though!
>>
>
> I would like to re-raise [&&x] as a shortcut for [x =3D
> std::move(x)] () mutable. It is seen extensively in continuation
> passing code, and since the language has first-class support for
> moves, lambdas should too.
>
>
> One could argue for the `&&x -> x =3D std::move(x)` part. But the=20
> automatic `mutable`-izing part? No. Whether you agree with the=20
> `const`-by-default nature of lambdas or not, we shouldn't create=20
> syntax that arbitrarily changes the nature of a lambda.
I see your point. How about, &&x translates to x =3D std::move(x) _and_ x=
=20
is a mutable member of the synthetic struct, even if `mutable` is not=20
specified?
> Also, do you really want to move from `x`?
I really do want to move from x. I have thousands of lines doing that,=20
though I expect a significant reduction when we start using coroutines.
> Or do you want to do a decay-copy into `x`? Because the latter is what=20
> `std::thread/async` do. And we already have a proposal for shortening=20
> that <http://wg21.link/P0644>.
>
This is wonderful. How about, in addition, a unary &&? &&x =3D=3D=20
std::move(x). std::move(x) is so common it deserves some syntax.
--=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/a0953525-1ab4-575b-2ced-09ea2182d9e4%40scylladb.=
com.
--------------35C4E91320960B8F13AB1739
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 08/15/2017 10:03 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:77a437cb-0cb3-4abb-a350-5dc72827073c@isocpp.org">
<div dir=3D"ltr">On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">Th=
is
paper proposes to remove two minor stumbling blocks to
the teachability of lambda syntax =E2=80=94 stumbling blo=
cks
of which many programmers may not even be aware.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;fo=
nt-size:medium">The
first is that=C2=A0</span><code style=3D"color:rgb(0,0,0)=
">[&x,
=3D](){ return x; }</code><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;fo=
nt-size:medium">=C2=A0is
ill-formed.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;fo=
nt-size:medium">The
second is that=C2=A0</span><code style=3D"color:rgb(0,0,0=
)">[=3D,
y](){ return x; }</code><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;fo=
nt-size:medium">=C2=A0is
ill-formed.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;fo=
nt-size:medium">I
propose to make both of these lambdas well-formed,
with the obvious meanings.</span></blockquote>
<div><br>
</div>
<a
href=3D"http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquu=
xplusone.github.io%2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplu=
sone.github.io%2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return
true;" moz-do-not-send=3D"true">http://quuxplusone.github.i=
o/<wbr>draft/liberal-syntax-for-<wbr>lambdas.html</a><br>
<div><br>
</div>
<div>Comments welcome, either here or via email. Remember
to read the paper first, though!</div>
<div><br>
</div>
</blockquote>
<br>
I would like to re-raise [&&x] as a shortcut for [x
=3D std::move(x)] () mutable.=C2=A0 It is seen extensively in
continuation passing code, and since the language has
first-class support for moves, lambdas should too.<br>
</div>
</blockquote>
<div><br>
One could argue for the `&&x -> x =3D std::move(x)`
part. But the automatic `mutable`-izing part? No. Whether you
agree with the `const`-by-default nature of lambdas or not, we
shouldn't create syntax that arbitrarily changes the nature of
a lambda. <br>
</div>
</div>
</blockquote>
<br>
I see your point. How about, &&x translates to x =3D
std::move(x) _and_ x is a mutable member of the synthetic struct,
even if `mutable` is not specified?<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:77a437cb-0cb3-4abb-a350-5dc72827073c@isocpp.org">
<div dir=3D"ltr">
<div>Also, do you really want to move from `x`?</div>
</div>
</blockquote>
<br>
I really do want to move from x. I have thousands of lines doing
that, though I expect a significant reduction when we start using
coroutines.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:77a437cb-0cb3-4abb-a350-5dc72827073c@isocpp.org">
<div dir=3D"ltr">
<div> Or do you want to do a decay-copy into `x`? Because the
latter is what `std::thread/async` do. And we <a
href=3D"http://wg21.link/P0644" moz-do-not-send=3D"true">alread=
y
have a proposal for shortening that</a>.<br>
</div>
</div>
<br>
</blockquote>
<br>
This is wonderful. How about, in addition, a unary &&?=C2=A0=C2=
=A0
&&x =3D=3D std::move(x).=C2=A0 std::move(x) is so common it des=
erves
some syntax.<br>
<br>
<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/a0953525-1ab4-575b-2ced-09ea2182d9e4%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/a0953525-1ab4-575b-2ced-09ea2182d9=
e4%40scylladb.com</a>.<br />
--------------35C4E91320960B8F13AB1739--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Aug 2017 08:08:00 -0700 (PDT)
Raw View
------=_Part_7707_1384862971.1502896080925
Content-Type: multipart/alternative;
boundary="----=_Part_7708_1268024086.1502896080925"
------=_Part_7708_1268024086.1502896080925
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>
> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>
> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:=20
>>
>> On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:
>>
>> This paper proposes to remove two minor stumbling blocks to the=20
>>> teachability of lambda syntax =E2=80=94 stumbling blocks of which many =
programmers=20
>>> may not even be aware.
>>> The first is that [&x, =3D](){ return x; } is ill-formed.
>>> The second is that [=3D, y](){ return x; } is ill-formed.
>>> I propose to make both of these lambdas well-formed, with the obvious=
=20
>>> meanings.
>>
>>
>> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html
>>
>> Comments welcome, either here or via email. Remember to read the paper=
=20
>> first, though!
>>
>>
>> I would like to re-raise [&&x] as a shortcut for [x =3D std::move(x)] ()=
=20
>> mutable. It is seen extensively in continuation passing code, and since=
=20
>> the language has first-class support for moves, lambdas should too.
>>
>
> One could argue for the `&&x -> x =3D std::move(x)` part. But the automat=
ic=20
> `mutable`-izing part? No. Whether you agree with the `const`-by-default=
=20
> nature of lambdas or not, we shouldn't create syntax that arbitrarily=20
> changes the nature of a lambda.=20
>
>
> I see your point. How about, &&x translates to x =3D std::move(x) _and_ x=
is=20
> a mutable member of the synthetic struct, even if `mutable` is not=20
> specified?
>
No. There's no reason to implicitly assume that, if a user wants to move an=
=20
object into the lambda, they also mean to modify it. These are two=20
orthogonal concepts.
If you move a `unique_ptr` into a lambda, that doesn't mean you're going to=
=20
modify the `unique_ptr` *itself*. You may modify what it points to, but=20
`unique_ptr` doesn't forward `const` through to `get`.
> Also, do you really want to move from `x`?
>
>
> I really do want to move from x. I have thousands of lines doing that,=20
> though I expect a significant reduction when we start using coroutines.
>
My question is why do you want to move there instead of decay-copying?
Or do you want to do a decay-copy into `x`? Because the latter is what=20
> `std::thread/async` do. And we already have a proposal for shortening tha=
t=20
> <http://wg21.link/P0644>.
>
>
> This is wonderful. How about, in addition, a unary &&? &&x =3D=3D=20
> std::move(x). std::move(x) is so common it deserves some syntax.
>
`std::move(x)` is sufficiently short that it doesn't need to be given=20
special syntax. It's 9 characters. By contrast,=20
"std::forward<decltype(x)>(x)` is 24 characters, not counting the size of=
=20
the `x` variable.
--=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/5df7a78d-847c-4c21-96d6-29c450823c6e%40isocpp.or=
g.
------=_Part_7708_1268024086.1502896080925
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kiv=
ity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/15/2017 10:03 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span style=3D"color:rgb(0,0,0);font-family:=
-webkit-standard;font-size:medium">This
paper proposes to remove two minor stumbling blocks to
the teachability of lambda syntax =E2=80=94 stumbling blo=
cks
of which many programmers may not even be aware.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-=
standard;font-size:medium">The
first is that=C2=A0</span><code style=3D"color:rgb(0,0,0)=
">[&x,
=3D](){ return x; }</code><span style=3D"color:rgb(0,0,0)=
;font-family:-webkit-standard;font-size:medium">=C2=A0is
ill-formed.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-=
standard;font-size:medium">The
second is that=C2=A0</span><code style=3D"color:rgb(0,0,0=
)">[=3D,
y](){ return x; }</code><span style=3D"color:rgb(0,0,0);f=
ont-family:-webkit-standard;font-size:medium">=C2=A0is
ill-formed.<br>
</span><span style=3D"color:rgb(0,0,0);font-family:-webkit-=
standard;font-size:medium">I
propose to make both of these lambdas well-formed,
with the obvious meanings.</span></blockquote>
<div><br>
</div>
<a href=3D"http://quuxplusone.github.io/draft/liberal-syntax-=
for-lambdas.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplusone.github.io=
%2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return true;" onclick=3D"this.hre=
f=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplusone.github.io%=
2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return true;">http://quuxplusone.g=
ithub.io/<wbr>draft/liberal-syntax-for-<wbr>lambdas.html</a><br>
<div><br>
</div>
<div>Comments welcome, either here or via email. Remember
to read the paper first, though!</div>
<div><br>
</div>
</blockquote>
<br>
I would like to re-raise [&&x] as a shortcut for [x
=3D std::move(x)] () mutable.=C2=A0 It is seen extensively in
continuation passing code, and since the language has
first-class support for moves, lambdas should too.<br>
</div>
</blockquote>
<div><br>
One could argue for the `&&x -> x =3D std::move(x)`
part. But the automatic `mutable`-izing part? No. Whether you
agree with the `const`-by-default nature of lambdas or not, we
shouldn't create syntax that arbitrarily changes the nature o=
f
a lambda. <br>
</div>
</div>
</blockquote>
<br>
I see your point. How about, &&x translates to x =3D
std::move(x) _and_ x is a mutable member of the synthetic struct,
even if `mutable` is not specified?<br></div></blockquote><div><br>No. =
There's no reason to implicitly assume that, if a user wants to move an=
object into the lambda, they also mean to modify it. These are two orthogo=
nal concepts.<br><br>If you move a `unique_ptr` into a lambda, that doesn&#=
39;t mean you're going to modify the `unique_ptr` *itself*. You may mod=
ify what it points to, but `unique_ptr` doesn't forward `const` through=
to `get`.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=
=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Also, do you really want to move from `x`?</div>
</div>
</blockquote>
<br>
I really do want to move from x. I have thousands of lines doing
that, though I expect a significant reduction when we start using
coroutines.<br></div></blockquote><div><br>My question is why do you wa=
nt to move there instead of decay-copying?<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> Or do you want to do a decay-copy into `x`? Because the
latter is what `std::thread/async` do. And we <a href=3D"http://w=
g21.link/P0644" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0644\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jgHgM2ZB1A';return=
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwg21.link%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ=
0zsZx5jgHgM2ZB1A';return true;">already
have a proposal for shortening that</a>.<br>
</div>
</div>
=20
</blockquote>
<br>
This is wonderful. How about, in addition, a unary &&?=C2=A0=C2=
=A0
&&x =3D=3D std::move(x).=C2=A0 std::move(x) is so common it des=
erves
some syntax.<br></div></blockquote><div><br>`std::move(x)` is sufficien=
tly short that it doesn't need to be given special syntax. It's 9 c=
haracters. By contrast, "std::forward<decltype(x)>(x)` is 24 cha=
racters, not counting the size of the `x` variable.<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/5df7a78d-847c-4c21-96d6-29c450823c6e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5df7a78d-847c-4c21-96d6-29c450823c6e=
%40isocpp.org</a>.<br />
------=_Part_7708_1268024086.1502896080925--
------=_Part_7707_1384862971.1502896080925--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 16 Aug 2017 10:22:58 -0700
Raw View
--94eb2c1b271cb9d5900556e22564
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>>>
>>> I would like to re-raise [&&x] as a shortcut for [x =3D std::move(x)] (=
)
>>> mutable. It is seen extensively in continuation passing code, and
since the
>>> language has first-class support for moves, lambdas should too.
>>
>> One could argue for the `&&x -> x =3D std::move(x)` part. But the automa=
tic
>> `mutable`-izing part? No. Whether you agree with the `const`-by-default
>> nature of lambdas or not, we shouldn't create syntax that arbitrarily
>> changes the nature of a lambda.
>>
>> I see your point. How about, &&x translates to x =3D std::move(x) _and_ =
x
is
>> a mutable member of the synthetic struct, even if `mutable` is not
>> specified?
>
> No. There's no reason to implicitly assume that, if a user wants to move
an
> object into the lambda, they also mean to modify it. These are two
> orthogonal concepts.
>
> If you move a `unique_ptr` into a lambda, that doesn't mean you're going
to
> modify the `unique_ptr` *itself*. You may modify what it points to, but
> `unique_ptr` doesn't forward `const` through to `get`.
>>
>> Also, do you really want to move from `x`?
>>
>> I really do want to move from x. I have thousands of lines doing that,
>> though I expect a significant reduction when we start using coroutines.
>
>
> My question is why do you want to move there instead of decay-copying?
My impression is that DECAY_COPY(x) always gives you a brand-new object
(that is, it literally does move the representation of x from one address
to another), whereas std::move(x) always gives you a reference (generally
an rvalue reference) that usually doesn't require any extra codegen.
I strongly suspect that when Avi is concerned with "move-only and mutable"
types, being captured by lambdas, potentially replaceable with coroutines,
the *specific* types he's thinking about are std::promise and/or
std::future. Using promises and futures with lambdas really *does* require
a lot of noisy "mutable" keywords; his use-case is valid.
But I don't want to see "implicit mutable" in the language at this point,
either. I'm certain that "mutable" should have been the default in 2011,
but now that ship has been sailed for 6 years; we can't get it back.
>> This is wonderful. How about, in addition, a unary &&? &&x =3D=3D
>> std::move(x). std::move(x) is so common it deserves some syntax.
>
> `std::move(x)` is sufficiently short that it doesn't need to be given
> special syntax. It's 9 characters. By contrast,
> "std::forward<decltype(x)>(x)` is 24 characters, not counting the size of
> the `x` variable.
Today I learned that Louis Dionne has a highly plausible proposal for
making "std::forward" lambda syntax consistent with the old non-lambda
syntax.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf
[](auto&& x) { return f(std::forward<decltype(x)>(x)); }
could after P0428
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf> be
written with named template parameters as
[]<class T>(T&& x) { return f(std::forward<T>(x)); }
Admittedly this is not as short as P0644
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r0.html>'s
syntax
[](auto&& x) { return f(>>x); }
or P0573
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r1.html>'s
syntax
x =3D> f(>>x)
but I think it's more friendly to standardization than either of those, and
at least the argument to std::forward wouldn't be gratuitously different
from the usual one, anymore.
=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/CADvuK0JKpO3S0Ua%3Dx%3Dn7oDgS9eBomL_JdjHRbNu-NFj=
tTLbmHw%40mail.gmail.com.
--94eb2c1b271cb9d5900556e22564
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>> =
On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:<br>>=
;> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>>> On Tuesday, Au=
gust 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:<br>>>><br>>=
;>> I would like to re-raise [&&x] as a shortcut for [x =3D s=
td::move(x)] ()<br>>>> mutable.=C2=A0 It is seen extensively in co=
ntinuation passing code, and since the<br>>>> language has first-c=
lass support for moves, lambdas should too.<br>>><br>>> One cou=
ld argue for the `&&x -> x =3D std::move(x)` part. But the autom=
atic<br>>> `mutable`-izing part? No. Whether you agree with the `cons=
t`-by-default<br>>> nature of lambdas or not, we shouldn't create=
syntax that arbitrarily<br>>> changes the nature of a lambda.<br>>=
;><br>>> I see your point. How about, &&x translates to x =
=3D std::move(x) _and_ x is<br>>> a mutable member of the synthetic s=
truct, even if `mutable` is not<br>>> specified?<br>><br>> No. =
There's no reason to implicitly assume that, if a user wants to move an=
<br>> object into the lambda, they also mean to modify it. These are two=
<br>> orthogonal concepts.<br>><br>> If you move a `unique_ptr` in=
to a lambda, that doesn't mean you're going to<br>> modify the `=
unique_ptr` *itself*. You may modify what it points to, but<br>> `unique=
_ptr` doesn't forward `const` through to `get`.<br>>><br>>>=
Also, do you really want to move from `x`?<br>>><br>>> I reall=
y do want to move from x. I have thousands of lines doing that,<br>>>=
though I expect a significant reduction when we start using coroutines.<br=
>><br>><br>> My question is why do you want to move there instead =
of decay-copying?<br><br>My impression is that DECAY_COPY(x) always gives y=
ou a brand-new object (that is, it literally does move the representation o=
f x from one address to another), whereas std::move(x) always gives you a r=
eference (generally an rvalue reference) that usually doesn't require a=
ny extra codegen.<div><br></div><div>I strongly suspect that when Avi is co=
ncerned with "move-only and mutable" types, being captured by lam=
bdas, potentially replaceable with coroutines, the <i>specific</i> types he=
's thinking about are std::promise and/or std::future. Using promises a=
nd futures with lambdas really <i>does</i> require a lot of noisy "mut=
able" keywords; his use-case is valid.</div><div><br></div><div>But I =
don't want to see "implicit mutable" in the language at this =
point, either. I'm certain that "mutable" should have been th=
e default in 2011, but now that ship has been sailed for 6 years; we can=
9;t get it back.</div><div><br></div><div><br>>> This is wonderful. H=
ow about, in addition, a unary &&? =C2=A0 &&x =3D=3D<br>>=
;> std::move(x). =C2=A0std::move(x) is so common it deserves some syntax=
..<br>><br>> `std::move(x)` is sufficiently short that it doesn't =
need to be given<br>> special syntax. It's 9 characters. By contrast=
,<br>> "std::forward<decltype(x)>(x)` is 24 characters, not c=
ounting the size of<br>> the `x` variable.<br></div><div><br></div><div>=
Today I learned that Louis Dionne has a highly plausible proposal for makin=
g "std::forward" lambda syntax consistent with the old non-lambda=
syntax.</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2017/p0428r2.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2017/p0428r2.pdf</a><br></div><div><br></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 [](auto&& x) { return f(std::forward<de=
cltype(x)>(x)); }</font></div><div><br></div><div>could after <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf">P0428=
</a> be written with named template parameters as</div><div><font face=3D"m=
onospace, monospace"><br></font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 []<class T>(T&& x) { return f(std::forward&=
lt;T>(x)); }</font></div><br>Admittedly this is not as short as <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r0.html">P=
0644</a>'s syntax<div><br><div><div><font face=3D"monospace, monospace"=
>=C2=A0 =C2=A0 [](auto&& x) { return f(>>x); }</font></div></=
div><br>or <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
17/p0573r1.html">P0573</a>'s syntax</div><div><br></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 x =3D> f(>>x)</font></div>=
<div><br></div><div>but I think it's more friendly to standardization t=
han either of those, and at least the argument to std::forward wouldn't=
be gratuitously different from the usual one, anymore.</div><div><br></div=
><div><div>=E2=80=93Arthur</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/CADvuK0JKpO3S0Ua%3Dx%3Dn7oDgS9eBomL_J=
djHRbNu-NFjtTLbmHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JKpO3S=
0Ua%3Dx%3Dn7oDgS9eBomL_JdjHRbNu-NFjtTLbmHw%40mail.gmail.com</a>.<br />
--94eb2c1b271cb9d5900556e22564--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Aug 2017 11:13:01 -0700 (PDT)
Raw View
------=_Part_78_1759597763.1502907181662
Content-Type: multipart/alternative;
boundary="----=_Part_79_272639812.1502907181662"
------=_Part_79_272639812.1502907181662
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 16, 2017 at 1:23:02 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
> >>>
> >>> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
> >>> mutable. It is seen extensively in continuation passing code, and
> since the
> >>> language has first-class support for moves, lambdas should too.
> >>
> >> One could argue for the `&&x -> x = std::move(x)` part. But the
> automatic
> >> `mutable`-izing part? No. Whether you agree with the `const`-by-default
> >> nature of lambdas or not, we shouldn't create syntax that arbitrarily
> >> changes the nature of a lambda.
> >>
> >> I see your point. How about, &&x translates to x = std::move(x) _and_ x
> is
> >> a mutable member of the synthetic struct, even if `mutable` is not
> >> specified?
> >
> > No. There's no reason to implicitly assume that, if a user wants to move
> an
> > object into the lambda, they also mean to modify it. These are two
> > orthogonal concepts.
> >
> > If you move a `unique_ptr` into a lambda, that doesn't mean you're going
> to
> > modify the `unique_ptr` *itself*. You may modify what it points to, but
> > `unique_ptr` doesn't forward `const` through to `get`.
> >>
> >> Also, do you really want to move from `x`?
> >>
> >> I really do want to move from x. I have thousands of lines doing that,
> >> though I expect a significant reduction when we start using coroutines.
> >
> >
> > My question is why do you want to move there instead of decay-copying?
>
> My impression is that DECAY_COPY(x) always gives you a brand-new object
> (that is, it literally does move the representation of x from one address
> to another), whereas std::move(x) always gives you a reference (generally
> an rvalue reference) that usually doesn't require any extra codegen.
>
> I strongly suspect that when Avi is concerned with "move-only and mutable"
> types, being captured by lambdas, potentially replaceable with coroutines,
> the *specific* types he's thinking about are std::promise and/or
> std::future. Using promises and futures with lambdas really *does*
> require a lot of noisy "mutable" keywords; his use-case is valid.
>
> But I don't want to see "implicit mutable" in the language at this point,
> either. I'm certain that "mutable" should have been the default in 2011,
> but now that ship has been sailed for 6 years; we can't get it back.
>
>
> >> This is wonderful. How about, in addition, a unary &&? &&x ==
> >> std::move(x). std::move(x) is so common it deserves some syntax.
> >
> > `std::move(x)` is sufficiently short that it doesn't need to be given
> > special syntax. It's 9 characters. By contrast,
> > "std::forward<decltype(x)>(x)` is 24 characters, not counting the size of
> > the `x` variable.
>
> Today I learned that Louis Dionne has a highly plausible proposal for
> making "std::forward" lambda syntax consistent with the old non-lambda
> syntax.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf
>
Which was added to the standard last month
<https://botondballo.wordpress.com/2017/08/02/trip-report-c-standards-meeting-in-toronto-july-2017/>
..
>
>
> [](auto&& x) { return f(std::forward<decltype(x)>(x)); }
>
> could after P0428
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf> be
> written with named template parameters as
>
> []<class T>(T&& x) { return f(std::forward<T>(x)); }
>
> Admittedly this is not as short as P0644
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r0.html>'s
> syntax
>
> [](auto&& x) { return f(>>x); }
>
> or P0573
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r1.html>'s
> syntax
>
> x => f(>>x)
>
> but I think it's more friendly to standardization than either of those,
> and at least the argument to std::forward wouldn't be gratuitously
> different from the usual one, anymore.
>
The committee seemed at least receptive to the `>>` syntax for forwarding (according
to this
<https://botondballo.wordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-2017/>),
which is why we got a separate paper for it. Don't assume failure before
the battle begins.
--
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/76f4fd70-7421-40b8-8240-9f597ed8b0fc%40isocpp.org.
------=_Part_79_272639812.1502907181662
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 1:23:02 PM UTC-4, Arthur =
O'Dwyer 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">On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"W8Cp0wG7CQAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>> =
wrote:<br>> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivit=
y wrote:<br>>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>>>=
On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:<br>>=
>><br>>>> I would like to re-raise [&&x] as a shortc=
ut for [x =3D std::move(x)] ()<br>>>> mutable.=C2=A0 It is seen ex=
tensively in continuation passing code, and since the<br>>>> langu=
age has first-class support for moves, lambdas should too.<br>>><br>&=
gt;> One could argue for the `&&x -> x =3D std::move(x)` part=
.. But the automatic<br>>> `mutable`-izing part? No. Whether you agree=
with the `const`-by-default<br>>> nature of lambdas or not, we shoul=
dn't create syntax that arbitrarily<br>>> changes the nature of a=
lambda.<br>>><br>>> I see your point. How about, &&x t=
ranslates to x =3D std::move(x) _and_ x is<br>>> a mutable member of =
the synthetic struct, even if `mutable` is not<br>>> specified?<br>&g=
t;<br>> No. There's no reason to implicitly assume that, if a user w=
ants to move an<br>> object into the lambda, they also mean to modify it=
.. These are two<br>> orthogonal concepts.<br>><br>> If you move a =
`unique_ptr` into a lambda, that doesn't mean you're going to<br>&g=
t; modify the `unique_ptr` *itself*. You may modify what it points to, but<=
br>> `unique_ptr` doesn't forward `const` through to `get`.<br>>&=
gt;<br>>> Also, do you really want to move from `x`?<br>>><br>&=
gt;> I really do want to move from x. I have thousands of lines doing th=
at,<br>>> though I expect a significant reduction when we start using=
coroutines.<br>><br>><br>> My question is why do you want to move=
there instead of decay-copying?<br><br>My impression is that DECAY_COPY(x)=
always gives you a brand-new object (that is, it literally does move the r=
epresentation of x from one address to another), whereas std::move(x) alway=
s gives you a reference (generally an rvalue reference) that usually doesn&=
#39;t require any extra codegen.<div><br></div><div>I strongly suspect that=
when Avi is concerned with "move-only and mutable" types, being =
captured by lambdas, potentially replaceable with coroutines, the <i>specif=
ic</i> types he's thinking about are std::promise and/or std::future. U=
sing promises and futures with lambdas really <i>does</i> require a lot of =
noisy "mutable" keywords; his use-case is valid.</div><div><br></=
div><div>But I don't want to see "implicit mutable" in the la=
nguage at this point, either. I'm certain that "mutable" shou=
ld have been the default in 2011, but now that ship has been sailed for 6 y=
ears; we can't get it back.</div><div><br></div><div><br>>> This =
is wonderful. How about, in addition, a unary &&? =C2=A0 &&=
x =3D=3D<br>>> std::move(x). =C2=A0std::move(x) is so common it deser=
ves some syntax.<br>><br>> `std::move(x)` is sufficiently short that =
it doesn't need to be given<br>> special syntax. It's 9 characte=
rs. By contrast,<br>> "std::forward<decltype(x)>(x)` is 24 ch=
aracters, not counting the size of<br>> the `x` variable.<br></div><div>=
<br></div><div>Today I learned that Louis Dionne has a highly plausible pro=
posal for making "std::forward" lambda syntax consistent with the=
old non-lambda syntax.</div><div><a href=3D"http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2017/p0428r2.pdf" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0428r2.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEP2F_Z5xWfbjRMh5lXyVt1NgWDxQ';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0=
428r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEP2F_Z5xWfbjRMh5lXyVt1NgW=
DxQ';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/pap=
ers/2017/<wbr>p0428r2.pdf</a></div></div></blockquote><div><br>Which was <a=
href=3D"https://botondballo.wordpress.com/2017/08/02/trip-report-c-standar=
ds-meeting-in-toronto-july-2017/">added to the standard last month</a>.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br></div><div><br></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 [](auto&& x) { return f(std::forward<decltype(x)>(=
x)<wbr>); }</font></div><div><br></div><div>could after <a href=3D"http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers=
%2F2017%2Fp0428r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEP2F_Z5xWfbjR=
Mh5lXyVt1NgWDxQ';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2017%2Fp0428r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEP2=
F_Z5xWfbjRMh5lXyVt1NgWDxQ';return true;">P0428</a> be written with name=
d template parameters as</div><div><font face=3D"monospace, monospace"><br>=
</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 []<c=
lass T>(T&& x) { return f(std::forward<T>(x)); }</font></d=
iv><br>Admittedly this is not as short as <a href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2017/p0644r0.html" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp06=
44r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYUyeR1P27JWJUClhMLrXqgzD=
ZBQ';return true;" onclick=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2017%2Fp0644r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYUyeR1P27JWJU=
ClhMLrXqgzDZBQ';return true;">P0644</a>'s syntax<div><br><div><div>=
<font face=3D"monospace, monospace">=C2=A0 =C2=A0 [](auto&& x) { re=
turn f(>>x); }</font></div></div><br>or <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2017/p0573r1.html" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017=
%2Fp0573r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8vJq2tjtVZKdbXZjfG=
02EmlMt9w';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2017%2Fp0573r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8vJq2tj=
tVZKdbXZjfG02EmlMt9w';return true;">P0573</a>'s syntax</div><div><b=
r></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 x =3D> f(=
>>x)</font></div><div><br></div><div>but I think it's more friend=
ly to standardization than either of those, and at least the argument to st=
d::forward wouldn't be gratuitously different from the usual one, anymo=
re.</div></div></blockquote><div><br>The committee seemed at least receptiv=
e to the `>>` syntax for forwarding (<a href=3D"https://botondballo.w=
ordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-20=
17/">according to this</a>), which is why we got a separate paper for it. D=
on't assume failure before the battle begins.<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/76f4fd70-7421-40b8-8240-9f597ed8b0fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76f4fd70-7421-40b8-8240-9f597ed8b0fc=
%40isocpp.org</a>.<br />
------=_Part_79_272639812.1502907181662--
------=_Part_78_1759597763.1502907181662--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 16 Aug 2017 22:44:09 +0300
Raw View
This is a multi-part message in MIME format.
--------------C65EFB461CA1A13078A22101
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 08/16/2017 06:08 PM, Nicol Bolas wrote:
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>
> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>>
>> On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:
>>>
>>> This paper proposes to remove two minor stumbling blocks
>>> to the teachability of lambda syntax =E2=80=94 stumbling bl=
ocks
>>> of which many programmers may not even be aware.
>>> The first is that |[&x, =3D](){ return x; }| is ill-formed.
>>> The second is that |[=3D, y](){ return x; }| is ill-formed.
>>> I propose to make both of these lambdas well-formed,
>>> with the obvious meanings.
>>>
>>>
>>> http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.h=
tml
>>> <http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.=
html>
>>>
>>> Comments welcome, either here or via email. Remember to read
>>> the paper first, though!
>>>
>>
>> I would like to re-raise [&&x] as a shortcut for [x =3D
>> std::move(x)] () mutable. It is seen extensively in
>> continuation passing code, and since the language has
>> first-class support for moves, lambdas should too.
>>
>>
>> One could argue for the `&&x -> x =3D std::move(x)` part. But the
>> automatic `mutable`-izing part? No. Whether you agree with the
>> `const`-by-default nature of lambdas or not, we shouldn't create
>> syntax that arbitrarily changes the nature of a lambda.
>
> I see your point. How about, &&x translates to x =3D std::move(x)
> _and_ x is a mutable member of the synthetic struct, even if
> `mutable` is not specified?
>
>
> No. There's no reason to implicitly assume that, if a user wants to=20
> move an object into the lambda, they also mean to modify it. These are=20
> two orthogonal concepts.
>
> If you move a `unique_ptr` into a lambda, that doesn't mean you're=20
> going to modify the `unique_ptr` *itself*. You may modify what it=20
> points to, but `unique_ptr` doesn't forward `const` through to `get`.
It is, in fact, very typical when passing continuations. The object you=20
moved into the lambda gets moved out into the next lambda when the=20
continuation runs.
Making capture-by-value variables const makes sense, because=20
modifications to them won't be reflected in the original variable, and=20
so an easy to use mistake is prevented. But by moving the source object=20
into the lambda you already declared you have no interest in it.
>> Also, do you really want to move from `x`?
>
> I really do want to move from x. I have thousands of lines doing
> that, though I expect a significant reduction when we start using
> coroutines.
>
>
> My question is why do you want to move there instead of decay-copying?
>
I have an object that is expensive to copy so I move it from=20
continuation to contination.
future<foo> f(expensive x) {
return foo1().then([x =3D std::move(x)] () mutable {
return foo2().then([x =3D std::move(x)] () mutable {
// do whatever with x
});
});
}
>> Or do you want to do a decay-copy into `x`? Because the latter is
>> what `std::thread/async` do. And we already have a proposal for
>> shortening that <http://wg21.link/P0644>.
>
> This is wonderful. How about, in addition, a unary &&? &&x =3D=3D
> std::move(x). std::move(x) is so common it deserves some syntax.
>
>
> `std::move(x)` is sufficiently short that it doesn't need to be given=20
> special syntax. It's 9 characters. By contrast,=20
> "std::forward<decltype(x)>(x)` is 24 characters, not counting the size=20
> of the `x` variable.
It's 9 characters for a very common operation. It's not uncommon to see=20
calls to std::move() dominate an expression visually, while contributing=20
little semantically. std::plus<>()(x, y) is also short, but it's not=20
something you want to use when doing math. Nor would you want=20
std::addressof() to take the address of a variable.
--=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/f2bf1129-92f7-7723-f0e0-8c47b0c32daa%40scylladb.=
com.
--------------C65EFB461CA1A13078A22101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 08/16/2017 06:08 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:5df7a78d-847c-4c21-96d6-29c450823c6e@isocpp.org">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Tuesday, August 15, 2017 at 2:29:27 PM
UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 07/17/2017 09:46 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">Th=
is
paper proposes to remove two minor stumbling
blocks to the teachability of lambda syntax =E2=
=80=94
stumbling blocks of which many programmers may
not even be aware.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-sta=
ndard;font-size:medium">The
first is that=C2=A0</span><code
style=3D"color:rgb(0,0,0)">[&x, =3D](){ retur=
n
x; }</code><span
style=3D"color:rgb(0,0,0);font-family:-webkit-sta=
ndard;font-size:medium">=C2=A0is
ill-formed.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-sta=
ndard;font-size:medium">The
second is that=C2=A0</span><code
style=3D"color:rgb(0,0,0)">[=3D, y](){ return x; =
}</code><span
style=3D"color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">=
=C2=A0is
ill-formed.<br>
</span><span
style=3D"color:rgb(0,0,0);font-family:-webkit-sta=
ndard;font-size:medium">I
propose to make both of these lambdas
well-formed, with the obvious meanings.</span></b=
lockquote>
<div><br>
</div>
<a
href=3D"http://quuxplusone.github.io/draft/liberal-syntax-for-lambdas.html"
rel=3D"nofollow" target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquu=
xplusone.github.io%2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fquuxplu=
sone.github.io%2Fdraft%2Fliberal-syntax-for-lambdas.html\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFei46vIflA1T7IvOrTxWoyeWVQfA';return
true;" moz-do-not-send=3D"true">http://quuxplusone.=
github.io/<wbr>draft/liberal-syntax-for-<wbr>lambdas.html</a><br>
<div><br>
</div>
<div>Comments welcome, either here or via email.
Remember to read the paper first, though!</div>
<div><br>
</div>
</blockquote>
<br>
I would like to re-raise [&&x] as a shortcut
for [x =3D std::move(x)] () mutable.=C2=A0 It is seen
extensively in continuation passing code, and since
the language has first-class support for moves,
lambdas should too.<br>
</div>
</blockquote>
<div><br>
One could argue for the `&&x -> x =3D
std::move(x)` part. But the automatic `mutable`-izing
part? No. Whether you agree with the
`const`-by-default nature of lambdas or not, we
shouldn't create syntax that arbitrarily changes the
nature of a lambda. <br>
</div>
</div>
</blockquote>
<br>
I see your point. How about, &&x translates to x =3D
std::move(x) _and_ x is a mutable member of the synthetic
struct, even if `mutable` is not specified?<br>
</div>
</blockquote>
<div><br>
No. There's no reason to implicitly assume that, if a user
wants to move an object into the lambda, they also mean to
modify it. These are two orthogonal concepts.<br>
<br>
If you move a `unique_ptr` into a lambda, that doesn't mean
you're going to modify the `unique_ptr` *itself*. You may
modify what it points to, but `unique_ptr` doesn't forward
`const` through to `get`.<br>
</div>
</div>
</blockquote>
<br>
It is, in fact, very typical when passing continuations. The object
you moved into the lambda gets moved out into the next lambda when
the continuation runs.<br>
<br>
Making capture-by-value variables const makes sense, because
modifications to them won't be reflected in the original variable,
and so an easy to use mistake is prevented. But by moving the source
object into the lambda you already declared you have no interest in
it.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:5df7a78d-847c-4c21-96d6-29c450823c6e@isocpp.org">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Also, do you really want to move from `x`?</div>
</div>
</blockquote>
<br>
I really do want to move from x. I have thousands of lines
doing that, though I expect a significant reduction when we
start using coroutines.<br>
</div>
</blockquote>
<div><br>
My question is why do you want to move there instead of
decay-copying?<br>
<br>
</div>
</div>
</blockquote>
<br>
I have an object that is expensive to copy so I move it from
continuation to contination.<br>
<br>
future<foo> f(expensive x) {<br>
=C2=A0=C2=A0=C2=A0 return foo1().then([x =3D std::move(x)] () mutable {=
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return foo2().then([x =3D st=
d::move(x)] () mutable {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 // do whatever with x<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 });<br>
=C2=A0=C2=A0=C2=A0 });<br>
}<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:5df7a78d-847c-4c21-96d6-29c450823c6e@isocpp.org">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> Or do you want to do a decay-copy into `x`?
Because the latter is what `std::thread/async` do. And
we <a href=3D"http://wg21.link/P0644" target=3D"_blank"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg2=
1.link%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jg=
HgM2ZB1A';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.li=
nk%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jgHgM2=
ZB1A';return
true;" moz-do-not-send=3D"true">already have a
proposal for shortening that</a>.<br>
</div>
</div>
</blockquote>
<br>
This is wonderful. How about, in addition, a unary
&&?=C2=A0=C2=A0 &&x =3D=3D std::move(x).=C2=A0 =
std::move(x) is
so common it deserves some syntax.<br>
</div>
</blockquote>
<div><br>
`std::move(x)` is sufficiently short that it doesn't need to
be given special syntax. It's 9 characters. By contrast,
"std::forward<decltype(x)>(x)` is 24 characters, not
counting the size of the `x` variable.<br>
</div>
</div>
</blockquote>
<br>
It's 9 characters for a very common operation. It's not uncommon to
see calls to std::move() dominate an expression visually, while
contributing little semantically. std::plus<>()(x, y) is also
short, but it's not something you want to use when doing math. Nor
would you want std::addressof() to take the address of a variable.<br>
<br>
<br>
<br>
<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/f2bf1129-92f7-7723-f0e0-8c47b0c32daa%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/f2bf1129-92f7-7723-f0e0-8c47b0c32d=
aa%40scylladb.com</a>.<br />
--------------C65EFB461CA1A13078A22101--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 16 Aug 2017 22:51:02 +0300
Raw View
This is a multi-part message in MIME format.
--------------D9490C60A6916F3667EE3B9C
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
> >>>
> >>> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
> >>> mutable. It is seen extensively in continuation passing code, and
> since the
> >>> language has first-class support for moves, lambdas should too.
> >>
> >> One could argue for the `&&x -> x = std::move(x)` part. But the
> automatic
> >> `mutable`-izing part? No. Whether you agree with the `const`-by-default
> >> nature of lambdas or not, we shouldn't create syntax that arbitrarily
> >> changes the nature of a lambda.
> >>
> >> I see your point. How about, &&x translates to x = std::move(x)
> _and_ x is
> >> a mutable member of the synthetic struct, even if `mutable` is not
> >> specified?
> >
> > No. There's no reason to implicitly assume that, if a user wants to
> move an
> > object into the lambda, they also mean to modify it. These are two
> > orthogonal concepts.
> >
> > If you move a `unique_ptr` into a lambda, that doesn't mean you're
> going to
> > modify the `unique_ptr` *itself*. You may modify what it points to, but
> > `unique_ptr` doesn't forward `const` through to `get`.
> >>
> >> Also, do you really want to move from `x`?
> >>
> >> I really do want to move from x. I have thousands of lines doing that,
> >> though I expect a significant reduction when we start using coroutines.
> >
> >
> > My question is why do you want to move there instead of decay-copying?
>
> My impression is that DECAY_COPY(x) always gives you a brand-new
> object (that is, it literally does move the representation of x from
> one address to another), whereas std::move(x) always gives you a
> reference (generally an rvalue reference) that usually doesn't require
> any extra codegen.
>
> I strongly suspect that when Avi is concerned with "move-only and
> mutable" types, being captured by lambdas, potentially replaceable
> with coroutines, the /specific/ types he's thinking about are
> std::promise and/or std::future. Using promises and futures with
> lambdas really /does/ require a lot of noisy "mutable" keywords; his
> use-case is valid.
>
Yes, future and promise (in the seastar namespace, not std, but same
usage). Usually it's not the future/promise types that are moved, but
state needed for continuations.
> But I don't want to see "implicit mutable" in the language at this
> point, either. I'm certain that "mutable" should have been the default
> in 2011, but now that ship has been sailed for 6 years; we can't get
> it back.
>
Not even for capture-by-move variable? Not the entire lambda. It's
likely that most lambdas that have a capture-by-move will also be mutable.
>
> >> This is wonderful. How about, in addition, a unary &&? &&x ==
> >> std::move(x). std::move(x) is so common it deserves some syntax.
> >
> > `std::move(x)` is sufficiently short that it doesn't need to be given
> > special syntax. It's 9 characters. By contrast,
> > "std::forward<decltype(x)>(x)` is 24 characters, not counting the
> size of
> > the `x` variable.
>
> Today I learned that Louis Dionne has a highly plausible proposal for
> making "std::forward" lambda syntax consistent with the old non-lambda
> syntax.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf
>
> [](auto&& x) { return f(std::forward<decltype(x)>(x)); }
>
> could after P0428
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf>
> be written with named template parameters as
>
> []<class T>(T&& x) { return f(std::forward<T>(x)); }
>
> Admittedly this is not as short as P0644
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r0.html>'s
> syntax
>
> [](auto&& x) { return f(>>x); }
>
> or P0573
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r1.html>'s
> syntax
>
> x => f(>>x)
>
> but I think it's more friendly to standardization than either of
> those, and at least the argument to std::forward wouldn't be
> gratuitously different from the usual one, anymore.
>
I hope that being user-friendly to users also counts!
--
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/9a0720ae-0a18-edbe-87db-6207d0a811ae%40scylladb.com.
--------------D9490C60A6916F3667EE3B9C
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 08/16/2017 08:22 PM, Arthur O'Dwyer
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CADvuK0JKpO3S0Ua=3Dx=3Dn7oDgS9eBomL_JdjHRbNu-NFjtTLbmHw@mail.gm=
ail.com">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <<a
href=3D"mailto:jmckesson@gmail.com" moz-do-not-send=3D"true">jmck=
esson@gmail.com</a>>
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi
Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi
Kivity wrote:<br>
>>><br>
>>> I would like to re-raise [&&x] as a
shortcut for [x =3D std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively in continuation
passing code, and since the<br>
>>> language has first-class support for moves, lambdas
should too.<br>
>><br>
>> One could argue for the `&&x -> x =3D
std::move(x)` part. But the automatic<br>
>> `mutable`-izing part? No. Whether you agree with the
`const`-by-default<br>
>> nature of lambdas or not, we shouldn't create syntax
that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about, &&x translates to
x =3D std::move(x) _and_ x is<br>
>> a mutable member of the synthetic struct, even if
`mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume that, if a user
wants to move an<br>
> object into the lambda, they also mean to modify it. These
are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda, that doesn't mean
you're going to<br>
> modify the `unique_ptr` *itself*. You may modify what it
points to, but<br>
> `unique_ptr` doesn't forward `const` through to `get`.<br>
>><br>
>> Also, do you really want to move from `x`?<br>
>><br>
>> I really do want to move from x. I have thousands of
lines doing that,<br>
>> though I expect a significant reduction when we start
using coroutines.<br>
><br>
><br>
> My question is why do you want to move there instead of
decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives you a brand-new
object (that is, it literally does move the representation of x
from one address to another), whereas std::move(x) always gives
you a reference (generally an rvalue reference) that usually
doesn't require any extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is concerned with
"move-only and mutable" types, being captured by lambdas,
potentially replaceable with coroutines, the <i>specific</i>
types he's thinking about are std::promise and/or std::future.
Using promises and futures with lambdas really <i>does</i>
require a lot of noisy "mutable" keywords; his use-case is
valid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace, not std, but same
usage). Usually it's not the future/promise types that are moved,
but state needed for continuations.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CADvuK0JKpO3S0Ua=3Dx=3Dn7oDgS9eBomL_JdjHRbNu-NFjtTLbmHw@mail.gm=
ail.com">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mutable" in the language
at this point, either. I'm certain that "mutable" should have
been the default in 2011, but now that ship has been sailed
for 6 years; we can't get it back.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the entire lambda. It's
likely that most lambdas that have a capture-by-move will also be
mutable.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CADvuK0JKpO3S0Ua=3Dx=3Dn7oDgS9eBomL_JdjHRbNu-NFjtTLbmHw@mail.gm=
ail.com">
<div dir=3D"ltr">
<div><br>
>> This is wonderful. How about, in addition, a unary
&&? =C2=A0 &&x =3D=3D<br>
>> std::move(x). =C2=A0std::move(x) is so common it deserve=
s
some syntax.<br>
><br>
> `std::move(x)` is sufficiently short that it doesn't need
to be given<br>
> special syntax. It's 9 characters. By contrast,<br>
> "std::forward<decltype(x)>(x)` is 24 characters,
not counting the size of<br>
> the `x` variable.<br>
</div>
<div><br>
</div>
<div>Today I learned that Louis Dionne has a highly plausible
proposal for making "std::forward" lambda syntax consistent
with the old non-lambda syntax.</div>
<div><a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf=
"
moz-do-not-send=3D"true">http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2017/p0428r2.pdf</a><br>
</div>
<div><br>
</div>
<div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 [](auto&=
& x)
{ return f(std::forward<decltype(x)>(x)); }</font></div>
<div><br>
</div>
<div>could after <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0428r2.pdf=
"
moz-do-not-send=3D"true">P0428</a> be written with named
template parameters as</div>
<div><font face=3D"monospace, monospace"><br>
</font></div>
<div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 []<class
T>(T&& x) { return f(std::forward<T>(x)); }</f=
ont></div>
<br>
Admittedly this is not as short as <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0644r0.htm=
l"
moz-do-not-send=3D"true">P0644</a>'s syntax
<div><br>
<div>
<div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 [](auto&=
amp;&
x) { return f(>>x); }</font></div>
</div>
<br>
or <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r1.htm=
l"
moz-do-not-send=3D"true">P0573</a>'s syntax</div>
<div><br>
</div>
<div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 x =3D> f(=
>>x)</font></div>
<div><br>
</div>
<div>but I think it's more friendly to standardization than
either of those, and at least the argument to std::forward
wouldn't be gratuitously different from the usual one,
anymore.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
I hope that being user-friendly to users also counts!<br>
<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/9a0720ae-0a18-edbe-87db-6207d0a811ae%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/9a0720ae-0a18-edbe-87db-6207d0a811=
ae%40scylladb.com</a>.<br />
--------------D9490C60A6916F3667EE3B9C--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Aug 2017 13:04:24 -0700 (PDT)
Raw View
------=_Part_258_82459726.1502913864556
Content-Type: multipart/alternative;
boundary="----=_Part_259_592428927.1502913864556"
------=_Part_259_592428927.1502913864556
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
>
> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
> >>>
> >>> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
> >>> mutable. It is seen extensively in continuation passing code, and
> since the
> >>> language has first-class support for moves, lambdas should too.
> >>
> >> One could argue for the `&&x -> x = std::move(x)` part. But the
> automatic
> >> `mutable`-izing part? No. Whether you agree with the `const`-by-default
> >> nature of lambdas or not, we shouldn't create syntax that arbitrarily
> >> changes the nature of a lambda.
> >>
> >> I see your point. How about, &&x translates to x = std::move(x) _and_ x
> is
> >> a mutable member of the synthetic struct, even if `mutable` is not
> >> specified?
> >
> > No. There's no reason to implicitly assume that, if a user wants to move
> an
> > object into the lambda, they also mean to modify it. These are two
> > orthogonal concepts.
> >
> > If you move a `unique_ptr` into a lambda, that doesn't mean you're going
> to
> > modify the `unique_ptr` *itself*. You may modify what it points to, but
> > `unique_ptr` doesn't forward `const` through to `get`.
> >>
> >> Also, do you really want to move from `x`?
> >>
> >> I really do want to move from x. I have thousands of lines doing that,
> >> though I expect a significant reduction when we start using coroutines.
> >
> >
> > My question is why do you want to move there instead of decay-copying?
>
> My impression is that DECAY_COPY(x) always gives you a brand-new object
> (that is, it literally does move the representation of x from one address
> to another), whereas std::move(x) always gives you a reference (generally
> an rvalue reference) that usually doesn't require any extra codegen.
>
> I strongly suspect that when Avi is concerned with "move-only and mutable"
> types, being captured by lambdas, potentially replaceable with coroutines,
> the *specific* types he's thinking about are std::promise and/or
> std::future. Using promises and futures with lambdas really *does*
> require a lot of noisy "mutable" keywords; his use-case is valid.
>
>
> Yes, future and promise (in the seastar namespace, not std, but same
> usage). Usually it's not the future/promise types that are moved, but state
> needed for continuations.
>
> But I don't want to see "implicit mutable" in the language at this point,
> either. I'm certain that "mutable" should have been the default in 2011,
> but now that ship has been sailed for 6 years; we can't get it back.
>
>
> Not even for capture-by-move variable? Not the entire lambda. It's likely
> that most lambdas that have a capture-by-move will also be mutable.
>
I would like to see some evidence for that statement. You're talking about
overturning a basic aspect of lambdas since they were standardized in 2011.
It's not something that we should just do willy nilly.
I have a strong dislike for the idea that `[x = std::move(x)]` should in
any way be different from `[&&x]`. There needs to be a *really* good reason
for doing that.
--
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/3ae6ee7f-d1e3-4a6a-b093-3e2cb5205720%40isocpp.org.
------=_Part_259_592428927.1502913864556
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kiv=
ity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 08:22 PM, Arthur O'Dwyer
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CBKeXxjDCQA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@=
gmail.com</a>>
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi
Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi
Kivity wrote:<br>
>>><br>
>>> I would like to re-raise [&&x] as a
shortcut for [x =3D std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively in continuation
passing code, and since the<br>
>>> language has first-class support for moves, lambdas
should too.<br>
>><br>
>> One could argue for the `&&x -> x =3D
std::move(x)` part. But the automatic<br>
>> `mutable`-izing part? No. Whether you agree with the
`const`-by-default<br>
>> nature of lambdas or not, we shouldn't create syntax
that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about, &&x translates to
x =3D std::move(x) _and_ x is<br>
>> a mutable member of the synthetic struct, even if
`mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume that, if a user
wants to move an<br>
> object into the lambda, they also mean to modify it. These
are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda, that doesn't mea=
n
you're going to<br>
> modify the `unique_ptr` *itself*. You may modify what it
points to, but<br>
> `unique_ptr` doesn't forward `const` through to `get`.<br>
>><br>
>> Also, do you really want to move from `x`?<br>
>><br>
>> I really do want to move from x. I have thousands of
lines doing that,<br>
>> though I expect a significant reduction when we start
using coroutines.<br>
><br>
><br>
> My question is why do you want to move there instead of
decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives you a brand-new
object (that is, it literally does move the representation of x
from one address to another), whereas std::move(x) always gives
you a reference (generally an rvalue reference) that usually
doesn't require any extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is concerned with
"move-only and mutable" types, being captured by lambda=
s,
potentially replaceable with coroutines, the <i>specific</i>
types he's thinking about are std::promise and/or std::future=
..
Using promises and futures with lambdas really <i>does</i>
require a lot of noisy "mutable" keywords; his use-case=
is
valid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace, not std, but same
usage). Usually it's not the future/promise types that are moved,
but state needed for continuations.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mutable" in th=
e language
at this point, either. I'm certain that "mutable" s=
hould have
been the default in 2011, but now that ship has been sailed
for 6 years; we can't get it back.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the entire lambda. It's
likely that most lambdas that have a capture-by-move will also be
mutable.<br></div></blockquote><div><br>I would like to see some eviden=
ce for that statement. You're talking about overturning a basic aspect =
of lambdas since they were standardized in 2011. It's not something tha=
t we should just do willy nilly.<br><br>I have a strong dislike for the ide=
a that `[x =3D std::move(x)]` should in any way be different from `[&&a=
mp;x]`. There needs to be a <i>really</i> good reason for doing that.</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/3ae6ee7f-d1e3-4a6a-b093-3e2cb5205720%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ae6ee7f-d1e3-4a6a-b093-3e2cb5205720=
%40isocpp.org</a>.<br />
------=_Part_259_592428927.1502913864556--
------=_Part_258_82459726.1502913864556--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Aug 2017 13:34:11 -0700 (PDT)
Raw View
------=_Part_287_842439630.1502915651426
Content-Type: multipart/alternative;
boundary="----=_Part_288_1144379793.1502915651427"
------=_Part_288_1144379793.1502915651427
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 16, 2017 at 3:44:20 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 06:08 PM, Nicol Bolas wrote:
>
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>>
> Also, do you really want to move from `x`?
>>
>>
>> I really do want to move from x. I have thousands of lines doing that,
>> though I expect a significant reduction when we start using coroutines.
>>
>
> My question is why do you want to move there instead of decay-copying?
>
>
> I have an object that is expensive to copy so I move it from continuation
> to contination.
>
> future<foo> f(expensive x) {
> return foo1().then([x = std::move(x)] () mutable {
> return foo2().then([x = std::move(x)] () mutable {
> // do whatever with x
> });
> });
> }
>
Can you give me an example that *wouldn't* be far more readable if
`co_await` got into C++20? I'm not a big fan of `co_await`, but it's
basically going to make your "mutable move capture" feature obsolete.
> Or do you want to do a decay-copy into `x`? Because the latter is what
>> `std::thread/async` do. And we already have a proposal for shortening
>> that <http://wg21.link/P0644>.
>>
>>
>> This is wonderful. How about, in addition, a unary &&? &&x ==
>> std::move(x). std::move(x) is so common it deserves some syntax.
>>
>
> `std::move(x)` is sufficiently short that it doesn't need to be given
> special syntax. It's 9 characters. By contrast,
> "std::forward<decltype(x)>(x)` is 24 characters, not counting the size of
> the `x` variable.
>
>
> It's 9 characters for a very common operation.
>
"very common operation" is based entirely on perspective. I don't do
continuation-style programming, so what you call "very common" is very much
not to me. Yes, a lot of people do this. But a lot of people *don't*. And
this feature will affect all of them, by forcing them to learn that lambdas
can sometimes have mutable captures without having the `mutable` keyword in
them.
It's not uncommon to see calls to std::move() dominate an expression
> visually, while contributing little semantically.
>
"Dominate an expression visually"? Sure. But what you're talking about
won't change that, since you're *only* talking about the case of lambda
captures. Most expressions where `std::move` dominates the expression are
variable declarations.
And I strongly disagree with the "contributing little semantically"
suggestion. It's *very* important in many cases to know when an object has
been moved from. Indeed, this was deliberately changed; earlier versions of
rvalue references were very happy to move things without having to use
`std::move`. That was changed because it make it too easy to break things
by accident.
And broadly speaking, continuation lambdas tend to not be on the short
side, so making their capture lists shorter isn't that important for
readability. By contrast, lambdas that do forwarding *do* tend to be quite
short. So making them shorter gives you more of an advantage.
std::plus<>()(x, y) is also short, but it's not something you want to use
> when doing math. Nor would you want std::addressof() to take the address of
> a variable.
>
--
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/ed2126d1-debe-43fe-b8bc-35c1a884cc5e%40isocpp.org.
------=_Part_288_1144379793.1502915651427
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:44:20 PM UTC-4, Avi Kiv=
ity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 06:08 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br></div></div>=
</blockquote></div></blockquote></div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Also, do you really want to move from `x`?</div>
</div>
</blockquote>
<br>
I really do want to move from x. I have thousands of lines
doing that, though I expect a significant reduction when we
start using coroutines.<br>
</div>
</blockquote>
<div><br>
My question is why do you want to move there instead of
decay-copying?<br>
<br>
</div>
</div>
</blockquote>
<br>
I have an object that is expensive to copy so I move it from
continuation to contination.<br>
<br>
future<foo> f(expensive x) {<br>
=C2=A0=C2=A0=C2=A0 return foo1().then([x =3D std::move(x)] () mutable {=
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return foo2().then([x =3D st=
d::move(x)] () mutable {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 // do whatever with x<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 });<br>
=C2=A0=C2=A0=C2=A0 });<br>
}<br></div></blockquote><div><br>Can you give me an example that <i>wou=
ldn't</i> be far more readable if `co_await` got into C++20? I'm no=
t a big fan of `co_await`, but it's basically going to make your "=
mutable move capture" feature obsolete.<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> Or do you want to do a decay-copy into `x`?
Because the latter is what `std::thread/async` do. And
we <a href=3D"http://wg21.link/P0644" rel=3D"nofollow" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwg21.link%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
G2EhMkSdIpFZ0zsZx5jgHgM2ZB1A';return true;" onclick=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0644\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jgHgM2ZB1A';return true;"=
>already have a
proposal for shortening that</a>.<br>
</div>
</div>
</blockquote>
<br>
This is wonderful. How about, in addition, a unary
&&?=C2=A0=C2=A0 &&x =3D=3D std::move(x).=C2=A0 =
std::move(x) is
so common it deserves some syntax.<br>
</div>
</blockquote>
<div><br>
`std::move(x)` is sufficiently short that it doesn't need to
be given special syntax. It's 9 characters. By contrast,
"std::forward<decltype(x)>(x)` is 24 characters, not
counting the size of the `x` variable.<br>
</div>
</div>
</blockquote>
<br>
It's 9 characters for a very common operation.</div></blockquote><d=
iv><br>"very common operation" is based entirely on perspective. =
I don't do continuation-style programming, so what you call "very =
common" is very much not to me. Yes, a lot of people do this. But a lo=
t of people <i>don't</i>. And this feature will affect all of them, by =
forcing them to learn that lambdas can sometimes have mutable captures with=
out having the `mutable` keyword in them.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">It's=
not uncommon to
see calls to std::move() dominate an expression visually, while
contributing little semantically.</div></blockquote><div><br>"Domi=
nate an expression visually"? Sure. But what you're talking about =
won't change that, since you're <i>only</i> talking about the case =
of lambda captures. Most expressions where `std::move` dominates the expres=
sion are variable declarations.<br><br>And I strongly disagree with the &qu=
ot;contributing little semantically" suggestion. It's <i>very</i> =
important in many cases to know when an object has been moved from. Indeed,=
this was deliberately changed; earlier versions of rvalue references were =
very happy to move things without having to use `std::move`. That was chang=
ed because it make it too easy to break things by accident.<br><br>And broa=
dly speaking, continuation lambdas tend to not be on the short side, so mak=
ing their capture lists shorter isn't that important for readability. B=
y contrast, lambdas that do forwarding <i>do</i> tend to be quite short. So=
making them shorter gives you more of an advantage.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFF=
F">std::plus<>()(x, y) is also
short, but it's not something you want to use when doing math. Nor
would you want std::addressof() to take the address of a variable.<br>
</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/ed2126d1-debe-43fe-b8bc-35c1a884cc5e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ed2126d1-debe-43fe-b8bc-35c1a884cc5e=
%40isocpp.org</a>.<br />
------=_Part_288_1144379793.1502915651427--
------=_Part_287_842439630.1502915651426--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 16 Aug 2017 23:39:04 +0300
Raw View
This is a multi-part message in MIME format.
--------------F05DCD62180A4F9C611A5F77
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 08/16/2017 11:04 PM, Nicol Bolas wrote:
> On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
>> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity
>> wrote:
>> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>> >>>
>> >>> I would like to re-raise [&&x] as a shortcut for [x =
>> std::move(x)] ()
>> >>> mutable. It is seen extensively in continuation passing
>> code, and since the
>> >>> language has first-class support for moves, lambdas should too.
>> >>
>> >> One could argue for the `&&x -> x = std::move(x)` part. But
>> the automatic
>> >> `mutable`-izing part? No. Whether you agree with the
>> `const`-by-default
>> >> nature of lambdas or not, we shouldn't create syntax that
>> arbitrarily
>> >> changes the nature of a lambda.
>> >>
>> >> I see your point. How about, &&x translates to x =
>> std::move(x) _and_ x is
>> >> a mutable member of the synthetic struct, even if `mutable` is not
>> >> specified?
>> >
>> > No. There's no reason to implicitly assume that, if a user
>> wants to move an
>> > object into the lambda, they also mean to modify it. These are two
>> > orthogonal concepts.
>> >
>> > If you move a `unique_ptr` into a lambda, that doesn't mean
>> you're going to
>> > modify the `unique_ptr` *itself*. You may modify what it points
>> to, but
>> > `unique_ptr` doesn't forward `const` through to `get`.
>> >>
>> >> Also, do you really want to move from `x`?
>> >>
>> >> I really do want to move from x. I have thousands of lines
>> doing that,
>> >> though I expect a significant reduction when we start using
>> coroutines.
>> >
>> >
>> > My question is why do you want to move there instead of
>> decay-copying?
>>
>> My impression is that DECAY_COPY(x) always gives you a brand-new
>> object (that is, it literally does move the representation of x
>> from one address to another), whereas std::move(x) always gives
>> you a reference (generally an rvalue reference) that usually
>> doesn't require any extra codegen.
>>
>> I strongly suspect that when Avi is concerned with "move-only and
>> mutable" types, being captured by lambdas, potentially
>> replaceable with coroutines, the /specific/ types he's thinking
>> about are std::promise and/or std::future. Using promises and
>> futures with lambdas really /does/ require a lot of noisy
>> "mutable" keywords; his use-case is valid.
>>
>
> Yes, future and promise (in the seastar namespace, not std, but
> same usage). Usually it's not the future/promise types that are
> moved, but state needed for continuations.
>
>> But I don't want to see "implicit mutable" in the language at
>> this point, either. I'm certain that "mutable" should have been
>> the default in 2011, but now that ship has been sailed for 6
>> years; we can't get it back.
>>
>
> Not even for capture-by-move variable? Not the entire lambda. It's
> likely that most lambdas that have a capture-by-move will also be
> mutable.
>
>
> I would like to see some evidence for that statement. You're talking
> about overturning a basic aspect of lambdas since they were
> standardized in 2011. It's not something that we should just do willy
> nilly.
>
Here's one sample:
$ git grep -E '\[.*=.*std::move.*\]' | wc -l
319
$ git grep -E '\[.*=.*std::move.*\].*mutable' | wc -l
142
So, about half. The ones that don't have mutable are either the last
continuation in the chain (so don't need to be moved out), or just
performance bugs - the move gets converted into a copy.
> I have a strong dislike for the idea that `[x = std::move(x)]` should
> in any way be different from `[&&x]`. There needs to be a /really/
> good reason for doing that.
The reason is, by making the lambda the owner of the contents, you're no
longer protecting the original object from missing a mutation.
By forcing the user to make the entire lambda mutable, you're reducing
the ability to detect this kind of bug on variables that _are_ copied by
value.
--
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/3047cc48-5036-87f4-0a4a-3ffbab329241%40scylladb.com.
--------------F05DCD62180A4F9C611A5F77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 08/16/2017 11:04 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:3ae6ee7f-d1e3-4a6a-b093-3e2cb5205720@isocpp.org">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM, Nicol
Bolas <<a href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"CBKeXxjDCQAJ" rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;"
moz-do-not-send=3D"true">jmck...@gmail.com</a>>
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4,
Avi Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27 PM
UTC-4, Avi Kivity wrote:<br>
>>><br>
>>> I would like to re-raise [&&x] as a
shortcut for [x =3D std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively in
continuation passing code, and since the<br>
>>> language has first-class support for moves,
lambdas should too.<br>
>><br>
>> One could argue for the `&&x -> x =3D
std::move(x)` part. But the automatic<br>
>> `mutable`-izing part? No. Whether you agree
with the `const`-by-default<br>
>> nature of lambdas or not, we shouldn't create
syntax that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about, &&x
translates to x =3D std::move(x) _and_ x is<br>
>> a mutable member of the synthetic struct, even
if `mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume that, if
a user wants to move an<br>
> object into the lambda, they also mean to modify
it. These are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda, that
doesn't mean you're going to<br>
> modify the `unique_ptr` *itself*. You may modify
what it points to, but<br>
> `unique_ptr` doesn't forward `const` through to
`get`.<br>
>><br>
>> Also, do you really want to move from `x`?<br>
>><br>
>> I really do want to move from x. I have
thousands of lines doing that,<br>
>> though I expect a significant reduction when we
start using coroutines.<br>
><br>
><br>
> My question is why do you want to move there
instead of decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives you a
brand-new object (that is, it literally does move the
representation of x from one address to another),
whereas std::move(x) always gives you a reference
(generally an rvalue reference) that usually doesn't
require any extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is concerned with
"move-only and mutable" types, being captured by
lambdas, potentially replaceable with coroutines, the
<i>specific</i> types he's thinking about are
std::promise and/or std::future. Using promises and
futures with lambdas really <i>does</i> require a lot
of noisy "mutable" keywords; his use-case is valid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace, not std,
but same usage). Usually it's not the future/promise types
that are moved, but state needed for continuations.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mutable" in the
language at this point, either. I'm certain that
"mutable" should have been the default in 2011, but
now that ship has been sailed for 6 years; we can't
get it back.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the entire
lambda. It's likely that most lambdas that have a
capture-by-move will also be mutable.<br>
</div>
</blockquote>
<div><br>
I would like to see some evidence for that statement. You're
talking about overturning a basic aspect of lambdas since they
were standardized in 2011. It's not something that we should
just do willy nilly.<br>
<br>
</div>
</div>
</blockquote>
<br>
Here's one sample:<br>
<br>
$ git grep -E '\[.*=3D.*std::move.*\]' | wc -l<br>
319<br>
$ git grep -E '\[.*=3D.*std::move.*\].*mutable' | wc -l<br>
142<br>
<br>
So, about half. The ones that don't have mutable are either the last
continuation in the chain (so don't need to be moved out), or just
performance bugs - the move gets converted into a copy.<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:3ae6ee7f-d1e3-4a6a-b093-3e2cb5205720@isocpp.org">
<div dir=3D"ltr">
<div>I have a strong dislike for the idea that `[x =3D
std::move(x)]` should in any way be different from
`[&&x]`. There needs to be a <i>really</i> good
reason for doing that.</div>
</div>
</blockquote>
<br>
The reason is, by making the lambda the owner of the contents,
you're no longer protecting the original object from missing a
mutation.<br>
<br>
By forcing the user to make the entire lambda mutable, you're
reducing the ability to detect this kind of bug on variables that
_are_ copied by value.<br>
<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/3047cc48-5036-87f4-0a4a-3ffbab329241%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/3047cc48-5036-87f4-0a4a-3ffbab3292=
41%40scylladb.com</a>.<br />
--------------F05DCD62180A4F9C611A5F77--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 16 Aug 2017 23:49:34 +0300
Raw View
This is a multi-part message in MIME format.
--------------38436D9DA758867E4FF2F3AC
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 08/16/2017 11:34 PM, Nicol Bolas wrote:
> On Wednesday, August 16, 2017 at 3:44:20 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 06:08 PM, Nicol Bolas wrote:
>> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>>
>>> Also, do you really want to move from `x`?
>>
>> I really do want to move from x. I have thousands of lines
>> doing that, though I expect a significant reduction when we
>> start using coroutines.
>>
>>
>> My question is why do you want to move there instead of
>> decay-copying?
>>
>
> I have an object that is expensive to copy so I move it from
> continuation to contination.
>
> future<foo> f(expensive x) {
> return foo1().then([x = std::move(x)] () mutable {
> return foo2().then([x = std::move(x)] () mutable {
> // do whatever with x
> });
> });
> }
>
>
> Can you give me an example that /wouldn't/ be far more readable if
> `co_await` got into C++20? I'm not a big fan of `co_await`, but it's
> basically going to make your "mutable move capture" feature obsolete.
I don't yet have experience with coroutines. I do hope they make this
usage of lambdas obsolete.
I plan to start making use of clang coroutines soon, even before
standardization, because of the great promise they show. But I still
think move-capture is useful,
but as you would say this is based less on evidence and more on feeling.
>>> Or do you want to do a decay-copy into `x`? Because the
>>> latter is what `std::thread/async` do. And we already have a
>>> proposal for shortening that <http://wg21.link/P0644>.
>>
>> This is wonderful. How about, in addition, a unary &&? &&x
>> == std::move(x). std::move(x) is so common it deserves some
>> syntax.
>>
>>
>> `std::move(x)` is sufficiently short that it doesn't need to be
>> given special syntax. It's 9 characters. By contrast,
>> "std::forward<decltype(x)>(x)` is 24 characters, not counting the
>> size of the `x` variable.
>
> It's 9 characters for a very common operation.
>
>
> "very common operation" is based entirely on perspective. I don't do
> continuation-style programming, so what you call "very common" is very
> much not to me. Yes, a lot of people do this. But a lot of people
> /don't/. And this feature will affect all of them, by forcing them to
> learn that lambdas can sometimes have mutable captures without having
> the `mutable` keyword in them.
>
If C++ was aiming to be a small, elegant, consistent language, then I
think it failed. At least it can try to be concise.
> It's not uncommon to see calls to std::move() dominate an
> expression visually, while contributing little semantically.
>
>
> "Dominate an expression visually"? Sure. But what you're talking about
> won't change that, since you're /only/ talking about the case of
> lambda captures. Most expressions where `std::move` dominates the
> expression are variable declarations.
No, above I also proposed a unary && operator (inspired by unary >>).
And moves are everywhere, in function calls particularly.
>
> And I strongly disagree with the "contributing little semantically"
> suggestion. It's /very/ important in many cases to know when an object
> has been moved from. Indeed, this was deliberately changed; earlier
> versions of rvalue references were very happy to move things without
> having to use `std::move`. That was changed because it make it too
> easy to break things by accident.
>
Of course it's important to know it, but it's less important than, say,
if you're passing x or y. Having the reference type dominate over the
variable name is not helping readability.
f(by_ref, &by_addr, &&moved)
vs
f(std::ref(by_ref), std::addressof(by_addr), std::move(moved))
the second is noisy and harder to read, IMO.
> And broadly speaking, continuation lambdas tend to not be on the short
> side, so making their capture lists shorter isn't that important for
> readability. By contrast, lambdas that do forwarding /do/ tend to be
> quite short. So making them shorter gives you more of an advantage.
>
I've seen a lot more move-capture lambdas than forwarding lambdas; but
of course that's just my use case. Forwarding is limited to generic
(library) code which is usually dominated by application code.
> std::plus<>()(x, y) is also short, but it's not something you want
> to use when doing math. Nor would you want std::addressof() to
> take the address of a variable.
>
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ed2126d1-debe-43fe-b8bc-35c1a884cc5e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ed2126d1-debe-43fe-b8bc-35c1a884cc5e%40isocpp.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02d1cc6e-a954-02b6-4803-2de4d52cb3aa%40scylladb.com.
--------------38436D9DA758867E4FF2F3AC
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 08/16/2017 11:34 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:44:20 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 06:08 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:47:32 AM
UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Also, do you really want to move from `x`?</di=
v>
</div>
</blockquote>
<br>
I really do want to move from x. I have thousands of
lines doing that, though I expect a significant
reduction when we start using coroutines.<br>
</div>
</blockquote>
<div><br>
My question is why do you want to move there instead
of decay-copying?<br>
<br>
</div>
</div>
</blockquote>
<br>
I have an object that is expensive to copy so I move it from
continuation to contination.<br>
<br>
future<foo> f(expensive x) {<br>
=C2=A0=C2=A0=C2=A0 return foo1().then([x =3D std::move(x)] () m=
utable {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return foo2().then([=
x =3D std::move(x)] () mutable {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 // do whatever with x<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 });<br>
=C2=A0=C2=A0=C2=A0 });<br>
}<br>
</div>
</blockquote>
<div><br>
Can you give me an example that <i>wouldn't</i> be far more
readable if `co_await` got into C++20? I'm not a big fan of
`co_await`, but it's basically going to make your "mutable
move capture" feature obsolete.<br>
</div>
</div>
</blockquote>
<br>
I don't yet have experience with coroutines. I do hope they make
this usage of lambdas obsolete.<br>
<br>
I plan to start making use of clang coroutines soon, even before
standardization, because of the great promise they show. But I still
think move-capture is useful,<br>
but as you would say this is based less on evidence and more on
feeling.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> Or do you want to do a decay-copy into
`x`? Because the latter is what
`std::thread/async` do. And we <a
href=3D"http://wg21.link/P0644" rel=3D"nofollow=
"
target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg2=
1.link%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jg=
HgM2ZB1A';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.li=
nk%2FP0644\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2EhMkSdIpFZ0zsZx5jgHgM2=
ZB1A';return
true;" moz-do-not-send=3D"true">already have a
proposal for shortening that</a>.<br>
</div>
</div>
</blockquote>
<br>
This is wonderful. How about, in addition, a unary
&&?=C2=A0=C2=A0 &&x =3D=3D std::move(x)=
..=C2=A0
std::move(x) is so common it deserves some syntax.<br>
</div>
</blockquote>
<div><br>
`std::move(x)` is sufficiently short that it doesn't
need to be given special syntax. It's 9 characters. By
contrast, "std::forward<decltype(x)>(x)` is 24
characters, not counting the size of the `x` variable.<br=
>
</div>
</div>
</blockquote>
<br>
It's 9 characters for a very common operation.</div>
</blockquote>
<div><br>
"very common operation" is based entirely on perspective. I
don't do continuation-style programming, so what you call
"very common" is very much not to me. Yes, a lot of people do
this. But a lot of people <i>don't</i>. And this feature will
affect all of them, by forcing them to learn that lambdas can
sometimes have mutable captures without having the `mutable`
keyword in them.<br>
<br>
</div>
</div>
</blockquote>
<br>
If C++ was aiming to be a small, elegant, consistent language, then
I think it failed. At least it can try to be concise.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">It's not uncommon to se=
e
calls to std::move() dominate an expression visually, while
contributing little semantically.</div>
</blockquote>
<div><br>
"Dominate an expression visually"? Sure. But what you're
talking about won't change that, since you're <i>only</i>
talking about the case of lambda captures. Most expressions
where `std::move` dominates the expression are variable
declarations.<br>
</div>
</div>
</blockquote>
<br>
No, above I also proposed a unary && operator (inspired by
unary >>). And moves are everywhere, in function calls
particularly.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">
<div><br>
And I strongly disagree with the "contributing little
semantically" suggestion. It's <i>very</i> important in many
cases to know when an object has been moved from. Indeed, this
was deliberately changed; earlier versions of rvalue
references were very happy to move things without having to
use `std::move`. That was changed because it make it too easy
to break things by accident.<br>
<br>
</div>
</div>
</blockquote>
<br>
Of course it's important to know it, but it's less important than,
say, if you're passing x or y. Having the reference type dominate
over the variable name is not helping readability.<br>
<br>
=C2=A0=C2=A0=C2=A0 f(by_ref, &by_addr, &&moved)<br>
<br>
vs<br>
<br>
=C2=A0=C2=A0=C2=A0 f(std::ref(by_ref), std::addressof(by_addr), std::mo=
ve(moved))<br>
<br>
the second is noisy and harder to read, IMO.<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">
<div>And broadly speaking, continuation lambdas tend to not be
on the short side, so making their capture lists shorter isn't
that important for readability. By contrast, lambdas that do
forwarding <i>do</i> tend to be quite short. So making them
shorter gives you more of an advantage.<br>
<br>
</div>
</div>
</blockquote>
<br>
I've seen a lot more move-capture lambdas than forwarding lambdas;
but of course that's just my use case. Forwarding is limited to
generic (library) code which is usually dominated by application
code.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:ed2126d1-debe-43fe-b8bc-35c1a884cc5e@isocpp.org">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">std::plus<>()(x,
y) is also short, but it's not something you want to use
when doing math. Nor would you want std::addressof() to take
the address of a variable.<br>
</div>
</blockquote>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ed2126=
d1-debe-43fe-b8bc-35c1a884cc5e%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/ed2126d1-debe-43fe-b8bc-35c1a884cc5e%40isocpp.org</a>.<b=
r>
</blockquote>
<p><br>
</p>
</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/02d1cc6e-a954-02b6-4803-2de4d52cb3aa%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/02d1cc6e-a954-02b6-4803-2de4d52cb3=
aa%40scylladb.com</a>.<br />
--------------38436D9DA758867E4FF2F3AC--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Aug 2017 14:00:09 -0700 (PDT)
Raw View
------=_Part_370_1548681248.1502917209790
Content-Type: multipart/alternative;
boundary="----=_Part_371_459854289.1502917209790"
------=_Part_371_459854289.1502917209790
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 11:04 PM, Nicol Bolas wrote:
>
> On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kivity wrote:
>>
>> On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
>>
>> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>> >>>
>> >>> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
>> >>> mutable. It is seen extensively in continuation passing code, and
>> since the
>> >>> language has first-class support for moves, lambdas should too.
>> >>
>> >> One could argue for the `&&x -> x = std::move(x)` part. But the
>> automatic
>> >> `mutable`-izing part? No. Whether you agree with the `const`-by-default
>> >> nature of lambdas or not, we shouldn't create syntax that arbitrarily
>> >> changes the nature of a lambda.
>> >>
>> >> I see your point. How about, &&x translates to x = std::move(x) _and_
>> x is
>> >> a mutable member of the synthetic struct, even if `mutable` is not
>> >> specified?
>> >
>> > No. There's no reason to implicitly assume that, if a user wants to
>> move an
>> > object into the lambda, they also mean to modify it. These are two
>> > orthogonal concepts.
>> >
>> > If you move a `unique_ptr` into a lambda, that doesn't mean you're
>> going to
>> > modify the `unique_ptr` *itself*. You may modify what it points to, but
>> > `unique_ptr` doesn't forward `const` through to `get`.
>> >>
>> >> Also, do you really want to move from `x`?
>> >>
>> >> I really do want to move from x. I have thousands of lines doing that,
>> >> though I expect a significant reduction when we start using coroutines.
>> >
>> >
>> > My question is why do you want to move there instead of decay-copying?
>>
>> My impression is that DECAY_COPY(x) always gives you a brand-new object
>> (that is, it literally does move the representation of x from one address
>> to another), whereas std::move(x) always gives you a reference (generally
>> an rvalue reference) that usually doesn't require any extra codegen.
>>
>> I strongly suspect that when Avi is concerned with "move-only and
>> mutable" types, being captured by lambdas, potentially replaceable with
>> coroutines, the *specific* types he's thinking about are std::promise
>> and/or std::future. Using promises and futures with lambdas really *does*
>> require a lot of noisy "mutable" keywords; his use-case is valid.
>>
>>
>> Yes, future and promise (in the seastar namespace, not std, but same
>> usage). Usually it's not the future/promise types that are moved, but state
>> needed for continuations.
>>
>> But I don't want to see "implicit mutable" in the language at this point,
>> either. I'm certain that "mutable" should have been the default in 2011,
>> but now that ship has been sailed for 6 years; we can't get it back.
>>
>>
>> Not even for capture-by-move variable? Not the entire lambda. It's likely
>> that most lambdas that have a capture-by-move will also be mutable.
>>
>
> I would like to see some evidence for that statement. You're talking about
> overturning a basic aspect of lambdas since they were standardized in 2011.
> It's not something that we should just do willy nilly.
>
> Here's one sample:
>
> $ git grep -E '\[.*=.*std::move.*\]' | wc -l
> 319
> $ git grep -E '\[.*=.*std::move.*\].*mutable' | wc -l
> 142
>
> So, about half. The ones that don't have mutable are either the last
> continuation in the chain (so don't need to be moved out), or just
> performance bugs - the move gets converted into a copy.
>
You made a very general statement: "It's likely that most lambdas that have
a capture-by-move will also be mutable." That statement did not limit
itself to code you're responsible for. So do you have evidence that this is
true of C++ code in general?
I have a strong dislike for the idea that `[x = std::move(x)]` should in
> any way be different from `[&&x]`. There needs to be a *really* good
> reason for doing that.
>
>
> The reason is, by making the lambda the owner of the contents, you're no
> longer protecting the original object from missing a mutation.
>
But *both of them* are making the lambda "the owner of the contents". My
question is why should one way of transferring ownership be different from
the other?
By forcing the user to make the entire lambda mutable, you're reducing the
> ability to detect this kind of bug on variables that _are_ copied by value.
>
I don't know what you mean by that. Your original declaration was that the
use of `&&x` in a capture list causes the lambda to become `mutable`:
> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
mutable.
Are you now saying that you want it to be limited to just `x` being
`mutable`? Wouldn't it make more sense to just allow you to do this
`[mutable &&x]`, `[mutable x = std::move(x)]` and so forth?
Why should mutability be tied to how the capture variable was initialized?
These are entirely orthogonal constructs, so they should be handled with
orthogonal syntax.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb5121e7-16e1-466f-beb8-8a892fa15991%40isocpp.org.
------=_Part_371_459854289.1502917209790
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4, Avi Kiv=
ity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 11:04 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM, Nicol
Bolas <<a rel=3D"nofollow">jmck...@gmail.com</a>>
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4,
Avi Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27 PM
UTC-4, Avi Kivity wrote:<br>
>>><br>
>>> I would like to re-raise [&&x] as a
shortcut for [x =3D std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively in
continuation passing code, and since the<br>
>>> language has first-class support for moves,
lambdas should too.<br>
>><br>
>> One could argue for the `&&x -> x =3D
std::move(x)` part. But the automatic<br>
>> `mutable`-izing part? No. Whether you agree
with the `const`-by-default<br>
>> nature of lambdas or not, we shouldn't create
syntax that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about, &&x
translates to x =3D std::move(x) _and_ x is<br>
>> a mutable member of the synthetic struct, even
if `mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume that, i=
f
a user wants to move an<br>
> object into the lambda, they also mean to modify
it. These are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda, that
doesn't mean you're going to<br>
> modify the `unique_ptr` *itself*. You may modify
what it points to, but<br>
> `unique_ptr` doesn't forward `const` through to
`get`.<br>
>><br>
>> Also, do you really want to move from `x`?<br>
>><br>
>> I really do want to move from x. I have
thousands of lines doing that,<br>
>> though I expect a significant reduction when we
start using coroutines.<br>
><br>
><br>
> My question is why do you want to move there
instead of decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives you a
brand-new object (that is, it literally does move the
representation of x from one address to another),
whereas std::move(x) always gives you a reference
(generally an rvalue reference) that usually doesn't
require any extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is concerned with
"move-only and mutable" types, being captured b=
y
lambdas, potentially replaceable with coroutines, the
<i>specific</i> types he's thinking about are
std::promise and/or std::future. Using promises and
futures with lambdas really <i>does</i> require a lot
of noisy "mutable" keywords; his use-case is va=
lid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace, not std,
but same usage). Usually it's not the future/promise types
that are moved, but state needed for continuations.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mutable&quo=
t; in the
language at this point, either. I'm certain that
"mutable" should have been the default in 2011,=
but
now that ship has been sailed for 6 years; we can't
get it back.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the entire
lambda. It's likely that most lambdas that have a
capture-by-move will also be mutable.<br>
</div>
</blockquote>
<div><br>
I would like to see some evidence for that statement. You're
talking about overturning a basic aspect of lambdas since they
were standardized in 2011. It's not something that we should
just do willy nilly.<br>
<br>
</div>
</div>
</blockquote>
=20
Here's one sample:<br>
<br>
$ git grep -E '\[.*=3D.*std::move.*\]' | wc -l<br>
319<br>
$ git grep -E '\[.*=3D.*std::move.*\].*<wbr>mutable' | wc -l<br=
>
142<br>
<br>
So, about half. The ones that don't have mutable are either the las=
t
continuation in the chain (so don't need to be moved out), or just
performance bugs - the move gets converted into a copy.<br></div></bloc=
kquote><div><br>You made a very general statement: "It's likely th=
at most lambdas that have a
capture-by-move will also be mutable." That statement did =
not limit itself to code you're responsible for. So do you have evidenc=
e that this is true of C++ code in general?<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>I have a strong dislike for the idea that `[x =3D
std::move(x)]` should in any way be different from
`[&&x]`. There needs to be a <i>really</i> good
reason for doing that.</div>
</div>
</blockquote>
<br>
The reason is, by making the lambda the owner of the contents,
you're no longer protecting the original object from missing a
mutation.<br></div></blockquote><div><br>But <i>both of them</i> are ma=
king the lambda "the owner of the contents". My question is why s=
hould one way of transferring ownership be different from the other?<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" b=
gcolor=3D"#FFFFFF">
=20
By forcing the user to make the entire lambda mutable, you're
reducing the ability to detect this kind of bug on variables that
_are_ copied by value.<br></div></blockquote><div><br>I don't know =
what you mean by that. Your original declaration was that the use of `&=
&x` in a capture list causes the lambda to become `mutable`:<br><br>>=
; I would like to re-raise [&&x] as a shortcut for [x =3D
std::move(x)] () mutable.<br><br>Are you now saying that you want it to=
be limited to just `x` being `mutable`? Wouldn't it make more sense to=
just allow you to do this `[mutable &&x]`, `[mutable x =3D std::mo=
ve(x)]` and so forth?<br><br>Why should mutability be tied to how the captu=
re variable was initialized? These are entirely orthogonal constructs, so t=
hey should be handled with orthogonal syntax.<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/eb5121e7-16e1-466f-beb8-8a892fa15991%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb5121e7-16e1-466f-beb8-8a892fa15991=
%40isocpp.org</a>.<br />
------=_Part_371_459854289.1502917209790--
------=_Part_370_1548681248.1502917209790--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Thu, 17 Aug 2017 10:16:40 +0300
Raw View
This is a multi-part message in MIME format.
--------------F83FE76CFFF7DB8F6F6CF556
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 08/17/2017 12:00 AM, Nicol Bolas wrote:
> On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4, Avi Kivity wrote:
>
> On 08/16/2017 11:04 PM, Nicol Bolas wrote:
>> On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kivity wrote:
>>
>> On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
>>> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas
>>> <jmck...@gmail.com> wrote:
>>> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi
>>> Kivity wrote:
>>> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>>> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi
>>> Kivity wrote:
>>> >>>
>>> >>> I would like to re-raise [&&x] as a shortcut for [x =
>>> std::move(x)] ()
>>> >>> mutable. It is seen extensively in continuation passing
>>> code, and since the
>>> >>> language has first-class support for moves, lambdas
>>> should too.
>>> >>
>>> >> One could argue for the `&&x -> x = std::move(x)` part.
>>> But the automatic
>>> >> `mutable`-izing part? No. Whether you agree with the
>>> `const`-by-default
>>> >> nature of lambdas or not, we shouldn't create syntax that
>>> arbitrarily
>>> >> changes the nature of a lambda.
>>> >>
>>> >> I see your point. How about, &&x translates to x =
>>> std::move(x) _and_ x is
>>> >> a mutable member of the synthetic struct, even if
>>> `mutable` is not
>>> >> specified?
>>> >
>>> > No. There's no reason to implicitly assume that, if a user
>>> wants to move an
>>> > object into the lambda, they also mean to modify it. These
>>> are two
>>> > orthogonal concepts.
>>> >
>>> > If you move a `unique_ptr` into a lambda, that doesn't
>>> mean you're going to
>>> > modify the `unique_ptr` *itself*. You may modify what it
>>> points to, but
>>> > `unique_ptr` doesn't forward `const` through to `get`.
>>> >>
>>> >> Also, do you really want to move from `x`?
>>> >>
>>> >> I really do want to move from x. I have thousands of
>>> lines doing that,
>>> >> though I expect a significant reduction when we start
>>> using coroutines.
>>> >
>>> >
>>> > My question is why do you want to move there instead of
>>> decay-copying?
>>>
>>> My impression is that DECAY_COPY(x) always gives you a
>>> brand-new object (that is, it literally does move the
>>> representation of x from one address to another), whereas
>>> std::move(x) always gives you a reference (generally an
>>> rvalue reference) that usually doesn't require any extra
>>> codegen.
>>>
>>> I strongly suspect that when Avi is concerned with
>>> "move-only and mutable" types, being captured by lambdas,
>>> potentially replaceable with coroutines, the /specific/
>>> types he's thinking about are std::promise and/or
>>> std::future. Using promises and futures with lambdas really
>>> /does/ require a lot of noisy "mutable" keywords; his
>>> use-case is valid.
>>>
>>
>> Yes, future and promise (in the seastar namespace, not std,
>> but same usage). Usually it's not the future/promise types
>> that are moved, but state needed for continuations.
>>
>>> But I don't want to see "implicit mutable" in the language
>>> at this point, either. I'm certain that "mutable" should
>>> have been the default in 2011, but now that ship has been
>>> sailed for 6 years; we can't get it back.
>>>
>>
>> Not even for capture-by-move variable? Not the entire lambda.
>> It's likely that most lambdas that have a capture-by-move
>> will also be mutable.
>>
>>
>> I would like to see some evidence for that statement. You're
>> talking about overturning a basic aspect of lambdas since they
>> were standardized in 2011. It's not something that we should just
>> do willy nilly.
>>
> Here's one sample:
>
> $ git grep -E '\[.*=.*std::move.*\]' | wc -l
> 319
> $ git grep -E '\[.*=.*std::move.*\].*mutable' | wc -l
> 142
>
> So, about half. The ones that don't have mutable are either the
> last continuation in the chain (so don't need to be moved out), or
> just performance bugs - the move gets converted into a copy.
>
>
> You made a very general statement: "It's likely that most lambdas that
> have a capture-by-move will also be mutable." That statement did not
> limit itself to code you're responsible for. So do you have evidence
> that this is true of C++ code in general?
Unfortunately, I do not.
The style of code used in my example, while not very common, is also not
specific to my application. So I expect my code would not be the only
beneficiary.
>
>> I have a strong dislike for the idea that `[x = std::move(x)]`
>> should in any way be different from `[&&x]`. There needs to be a
>> /really/ good reason for doing that.
>
> The reason is, by making the lambda the owner of the contents,
> you're no longer protecting the original object from missing a
> mutation.
>
>
> But /both of them/ are making the lambda "the owner of the contents".
> My question is why should one way of transferring ownership be
> different from the other?
Because one way is set in stone and cannot be modified. The other way
can still be changed, and it should be chosen to fit the user's needs,
not an overriding sense of consistency. Consistency is good, but it's
not something that C++ will be good at. I'm not proposing that we should
ignore it, just that it should not be the top priority.
>
> By forcing the user to make the entire lambda mutable, you're
> reducing the ability to detect this kind of bug on variables that
> _are_ copied by value.
>
>
> I don't know what you mean by that. Your original declaration was that
> the use of `&&x` in a capture list causes the lambda to become `mutable`:
>
> > I would like to re-raise [&&x] as a shortcut for [x = std::move(x)]
> () mutable.
>
> Are you now saying that you want it to be limited to just `x` being
> `mutable`? Wouldn't it make more sense to just allow you to do this
> `[mutable &&x]`, `[mutable x = std::move(x)]` and so forth?
I changed my position a few emails ago, you must have missed it.
I do like [mutable x], but it will be rare. [mutable &&x] on the other
hand will be very common, and on many occasions forgetting it will be a
subtle mistake (for copy/move types) or a compile error (for move-only
types) so to remove this class of error it should be the default.
>
> Why should mutability be tied to how the capture variable was
> initialized? These are entirely orthogonal constructs, so they should
> be handled with orthogonal syntax.
>
Because, for copy capture, const is the sensible bug-preventing default,
while for move-capture, mutable is the sensible bug-preventing default.
--
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/cbf07055-0e84-9401-9c7e-2243372663c2%40scylladb.com.
--------------F83FE76CFFF7DB8F6F6CF556
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 08/17/2017 12:00 AM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:eb5121e7-16e1-466f-beb8-8a892fa15991@isocpp.org">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 11:04 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:51:15 PM
UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM,
Nicol Bolas <<a rel=3D"nofollow"
moz-do-not-send=3D"true">jmck...@gmail.com</a>>=
;
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM
UTC-4, Avi Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas
wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27
PM UTC-4, Avi Kivity wrote:<br>
>>><br>
>>> I would like to re-raise
[&&x] as a shortcut for [x =3D
std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively =
in
continuation passing code, and since the<br>
>>> language has first-class support
for moves, lambdas should too.<br>
>><br>
>> One could argue for the `&&x
-> x =3D std::move(x)` part. But the automatic<b=
r>
>> `mutable`-izing part? No. Whether you
agree with the `const`-by-default<br>
>> nature of lambdas or not, we shouldn't
create syntax that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about,
&&x translates to x =3D std::move(x) _and_
x is<br>
>> a mutable member of the synthetic
struct, even if `mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume
that, if a user wants to move an<br>
> object into the lambda, they also mean to
modify it. These are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda,
that doesn't mean you're going to<br>
> modify the `unique_ptr` *itself*. You may
modify what it points to, but<br>
> `unique_ptr` doesn't forward `const`
through to `get`.<br>
>><br>
>> Also, do you really want to move from
`x`?<br>
>><br>
>> I really do want to move from x. I have
thousands of lines doing that,<br>
>> though I expect a significant reduction
when we start using coroutines.<br>
><br>
><br>
> My question is why do you want to move
there instead of decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives
you a brand-new object (that is, it literally
does move the representation of x from one
address to another), whereas std::move(x) always
gives you a reference (generally an rvalue
reference) that usually doesn't require any
extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is
concerned with "move-only and mutable" types,
being captured by lambdas, potentially
replaceable with coroutines, the <i>specific</i>
types he's thinking about are std::promise
and/or std::future. Using promises and futures
with lambdas really <i>does</i> require a lot
of noisy "mutable" keywords; his use-case is
valid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace,
not std, but same usage). Usually it's not the
future/promise types that are moved, but state
needed for continuations.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mutable"
in the language at this point, either. I'm
certain that "mutable" should have been the
default in 2011, but now that ship has been
sailed for 6 years; we can't get it back.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the
entire lambda. It's likely that most lambdas that
have a capture-by-move will also be mutable.<br>
</div>
</blockquote>
<div><br>
I would like to see some evidence for that statement.
You're talking about overturning a basic aspect of
lambdas since they were standardized in 2011. It's not
something that we should just do willy nilly.<br>
<br>
</div>
</div>
</blockquote>
Here's one sample:<br>
<br>
$ git grep -E '\[.*=3D.*std::move.*\]' | wc -l<br>
319<br>
$ git grep -E '\[.*=3D.*std::move.*\].*<wbr>mutable' | wc -l<br=
>
142<br>
<br>
So, about half. The ones that don't have mutable are either
the last continuation in the chain (so don't need to be
moved out), or just performance bugs - the move gets
converted into a copy.<br>
</div>
</blockquote>
<div><br>
You made a very general statement: "It's likely that most
lambdas that have a capture-by-move will also be mutable."
That statement did not limit itself to code you're responsible
for. So do you have evidence that this is true of C++ code in
general?<br>
</div>
</div>
</blockquote>
<br>
Unfortunately, I do not.<br>
<br>
The style of code used in my example, while not very common, is also
not specific to my application. So I expect my code would not be the
only beneficiary.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:eb5121e7-16e1-466f-beb8-8a892fa15991@isocpp.org">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>I have a strong dislike for the idea that `[x =3D
std::move(x)]` should in any way be different from
`[&&x]`. There needs to be a <i>really</i>
good reason for doing that.</div>
</div>
</blockquote>
<br>
The reason is, by making the lambda the owner of the
contents, you're no longer protecting the original object
from missing a mutation.<br>
</div>
</blockquote>
<div><br>
But <i>both of them</i> are making the lambda "the owner of
the contents". My question is why should one way of
transferring ownership be different from the other?<br>
</div>
</div>
</blockquote>
<br>
Because one way is set in stone and cannot be modified. The other
way can still be changed, and it should be chosen to fit the user's
needs, not an overriding sense of consistency. Consistency is good,
but it's not something that C++ will be good at. I'm not proposing
that we should ignore it, just that it should not be the top
priority.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:eb5121e7-16e1-466f-beb8-8a892fa15991@isocpp.org">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> By forcing the user to
make the entire lambda mutable, you're reducing the ability
to detect this kind of bug on variables that _are_ copied by
value.<br>
</div>
</blockquote>
<div><br>
I don't know what you mean by that. Your original declaration
was that the use of `&&x` in a capture list causes the
lambda to become `mutable`:<br>
<br>
> I would like to re-raise [&&x] as a shortcut for
[x =3D std::move(x)] () mutable.<br>
<br>
Are you now saying that you want it to be limited to just `x`
being `mutable`? Wouldn't it make more sense to just allow you
to do this `[mutable &&x]`, `[mutable x =3D
std::move(x)]` and so forth?<br>
</div>
</div>
</blockquote>
<br>
I changed my position a few emails ago, you must have missed it.<br>
<br>
I do like [mutable x], but it will be rare. [mutable &&x] on
the other hand will be very common, and on many occasions forgetting
it will be a subtle mistake (for copy/move types) or a compile error
(for move-only types) so to remove this class of error it should be
the default.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:eb5121e7-16e1-466f-beb8-8a892fa15991@isocpp.org">
<div dir=3D"ltr">
<div><br>
Why should mutability be tied to how the capture variable was
initialized? These are entirely orthogonal constructs, so they
should be handled with orthogonal syntax.<br>
</div>
</div>
<br>
</blockquote>
<br>
Because, for copy capture, const is the sensible bug-preventing
default, while for move-capture, mutable is the sensible
bug-preventing default.<br>
<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/cbf07055-0e84-9401-9c7e-2243372663c2%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/cbf07055-0e84-9401-9c7e-2243372663=
c2%40scylladb.com</a>.<br />
--------------F83FE76CFFF7DB8F6F6CF556--
.
Author: Ryan Nicholl <r.p.nicholl@gmail.com>
Date: Wed, 23 Aug 2017 16:29:20 -0700 (PDT)
Raw View
------=_Part_188_1054843487.1503530960384
Content-Type: multipart/alternative;
boundary="----=_Part_189_1061616845.1503530960385"
------=_Part_189_1061616845.1503530960385
Content-Type: text/plain; charset="UTF-8"
I think we should prefer consistency of the lambda behavior being const. A
move construction that is const is not always wrong. If the value does not
need to be modified later but needs to be preserved because the lifetime of
the input is ending then &&x makes sense.
However, [mutable &&x] I think is better than the alternative of [const
&&x], lambdas are implicitly const. Leaving that alone is probably best.
Making the const-ness of values depend on the way they are initialized
doesn't make sense, no matter the common use cases.
On Thursday, August 17, 2017 at 3:16:46 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 08/17/2017 12:00 AM, Nicol Bolas wrote:
>
> On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4, Avi Kivity wrote:
>>
>> On 08/16/2017 11:04 PM, Nicol Bolas wrote:
>>
>> On Wednesday, August 16, 2017 at 3:51:15 PM UTC-4, Avi Kivity wrote:
>>>
>>> On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:
>>>
>>> On Wed, Aug 16, 2017 at 8:08 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>> > On Wednesday, August 16, 2017 at 4:47:32 AM UTC-4, Avi Kivity wrote:
>>> >> On 08/15/2017 10:03 PM, Nicol Bolas wrote:
>>> >> On Tuesday, August 15, 2017 at 2:29:27 PM UTC-4, Avi Kivity wrote:
>>> >>>
>>> >>> I would like to re-raise [&&x] as a shortcut for [x = std::move(x)]
>>> ()
>>> >>> mutable. It is seen extensively in continuation passing code, and
>>> since the
>>> >>> language has first-class support for moves, lambdas should too.
>>> >>
>>> >> One could argue for the `&&x -> x = std::move(x)` part. But the
>>> automatic
>>> >> `mutable`-izing part? No. Whether you agree with the
>>> `const`-by-default
>>> >> nature of lambdas or not, we shouldn't create syntax that arbitrarily
>>> >> changes the nature of a lambda.
>>> >>
>>> >> I see your point. How about, &&x translates to x = std::move(x) _and_
>>> x is
>>> >> a mutable member of the synthetic struct, even if `mutable` is not
>>> >> specified?
>>> >
>>> > No. There's no reason to implicitly assume that, if a user wants to
>>> move an
>>> > object into the lambda, they also mean to modify it. These are two
>>> > orthogonal concepts.
>>> >
>>> > If you move a `unique_ptr` into a lambda, that doesn't mean you're
>>> going to
>>> > modify the `unique_ptr` *itself*. You may modify what it points to, but
>>> > `unique_ptr` doesn't forward `const` through to `get`.
>>> >>
>>> >> Also, do you really want to move from `x`?
>>> >>
>>> >> I really do want to move from x. I have thousands of lines doing that,
>>> >> though I expect a significant reduction when we start using
>>> coroutines.
>>> >
>>> >
>>> > My question is why do you want to move there instead of decay-copying?
>>>
>>> My impression is that DECAY_COPY(x) always gives you a brand-new object
>>> (that is, it literally does move the representation of x from one address
>>> to another), whereas std::move(x) always gives you a reference (generally
>>> an rvalue reference) that usually doesn't require any extra codegen.
>>>
>>> I strongly suspect that when Avi is concerned with "move-only and
>>> mutable" types, being captured by lambdas, potentially replaceable with
>>> coroutines, the *specific* types he's thinking about are std::promise
>>> and/or std::future. Using promises and futures with lambdas really
>>> *does* require a lot of noisy "mutable" keywords; his use-case is valid.
>>>
>>>
>>> Yes, future and promise (in the seastar namespace, not std, but same
>>> usage). Usually it's not the future/promise types that are moved, but state
>>> needed for continuations.
>>>
>>> But I don't want to see "implicit mutable" in the language at this
>>> point, either. I'm certain that "mutable" should have been the default in
>>> 2011, but now that ship has been sailed for 6 years; we can't get it back.
>>>
>>>
>>> Not even for capture-by-move variable? Not the entire lambda. It's
>>> likely that most lambdas that have a capture-by-move will also be mutable.
>>>
>>
>> I would like to see some evidence for that statement. You're talking
>> about overturning a basic aspect of lambdas since they were standardized in
>> 2011. It's not something that we should just do willy nilly.
>>
>> Here's one sample:
>>
>> $ git grep -E '\[.*=.*std::move.*\]' | wc -l
>> 319
>> $ git grep -E '\[.*=.*std::move.*\].*mutable' | wc -l
>> 142
>>
>> So, about half. The ones that don't have mutable are either the last
>> continuation in the chain (so don't need to be moved out), or just
>> performance bugs - the move gets converted into a copy.
>>
>
> You made a very general statement: "It's likely that most lambdas that
> have a capture-by-move will also be mutable." That statement did not limit
> itself to code you're responsible for. So do you have evidence that this is
> true of C++ code in general?
>
>
> Unfortunately, I do not.
>
> The style of code used in my example, while not very common, is also not
> specific to my application. So I expect my code would not be the only
> beneficiary.
>
>
> I have a strong dislike for the idea that `[x = std::move(x)]` should in
>> any way be different from `[&&x]`. There needs to be a *really* good
>> reason for doing that.
>>
>>
>> The reason is, by making the lambda the owner of the contents, you're no
>> longer protecting the original object from missing a mutation.
>>
>
> But *both of them* are making the lambda "the owner of the contents". My
> question is why should one way of transferring ownership be different from
> the other?
>
>
> Because one way is set in stone and cannot be modified. The other way can
> still be changed, and it should be chosen to fit the user's needs, not an
> overriding sense of consistency. Consistency is good, but it's not
> something that C++ will be good at. I'm not proposing that we should ignore
> it, just that it should not be the top priority.
>
>
> By forcing the user to make the entire lambda mutable, you're reducing the
>> ability to detect this kind of bug on variables that _are_ copied by value.
>>
>
> I don't know what you mean by that. Your original declaration was that the
> use of `&&x` in a capture list causes the lambda to become `mutable`:
>
> > I would like to re-raise [&&x] as a shortcut for [x = std::move(x)] ()
> mutable.
>
> Are you now saying that you want it to be limited to just `x` being
> `mutable`? Wouldn't it make more sense to just allow you to do this
> `[mutable &&x]`, `[mutable x = std::move(x)]` and so forth?
>
>
> I changed my position a few emails ago, you must have missed it.
>
> I do like [mutable x], but it will be rare. [mutable &&x] on the other
> hand will be very common, and on many occasions forgetting it will be a
> subtle mistake (for copy/move types) or a compile error (for move-only
> types) so to remove this class of error it should be the default.
>
>
> Why should mutability be tied to how the capture variable was initialized?
> These are entirely orthogonal constructs, so they should be handled with
> orthogonal syntax.
>
>
> Because, for copy capture, const is the sensible bug-preventing default,
> while for move-capture, mutable is the sensible bug-preventing default.
>
>
--
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/2aff507c-b712-413a-b8d2-495e1533e96f%40isocpp.org.
------=_Part_189_1061616845.1503530960385
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think we should prefer consistency of the lambda behavio=
r being const. A move construction that is const is not always wrong. If th=
e value does not need to be modified later but needs to be preserved becaus=
e the lifetime of the input is ending then &&x makes sense.<br>Howe=
ver, [mutable &&x] I think is better than the alternative of [const=
&&x], lambdas are implicitly const. Leaving that alone is probably=
best. Making the const-ness of values depend on the way they are initializ=
ed doesn't make sense, no matter the common use cases.<br><br>On Thursd=
ay, August 17, 2017 at 3:16:46 AM UTC-4, Avi Kivity wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 08/17/2017 12:00 AM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 4:39:18 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 11:04 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wednesday, August 16, 2017 at 3:51:15 PM
UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 08/16/2017 08:22 PM, Arthur O'Dwyer wrote:<=
br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Wed, Aug 16, 2017 at 8:08 AM,
Nicol Bolas <<a rel=3D"nofollow">jmck...@gmail.c=
om</a>>
wrote:<br>
> On Wednesday, August 16, 2017 at 4:47:32 AM
UTC-4, Avi Kivity wrote:<br>
>> On 08/15/2017 10:03 PM, Nicol Bolas
wrote:<br>
>> On Tuesday, August 15, 2017 at 2:29:27
PM UTC-4, Avi Kivity wrote:<br>
>>><br>
>>> I would like to re-raise
[&&x] as a shortcut for [x =3D
std::move(x)] ()<br>
>>> mutable.=C2=A0 It is seen extensively =
in
continuation passing code, and since the<br>
>>> language has first-class support
for moves, lambdas should too.<br>
>><br>
>> One could argue for the `&&x
-> x =3D std::move(x)` part. But the automatic<b=
r>
>> `mutable`-izing part? No. Whether you
agree with the `const`-by-default<br>
>> nature of lambdas or not, we shouldn't
create syntax that arbitrarily<br>
>> changes the nature of a lambda.<br>
>><br>
>> I see your point. How about,
&&x translates to x =3D std::move(x) _and_
x is<br>
>> a mutable member of the synthetic
struct, even if `mutable` is not<br>
>> specified?<br>
><br>
> No. There's no reason to implicitly assume
that, if a user wants to move an<br>
> object into the lambda, they also mean to
modify it. These are two<br>
> orthogonal concepts.<br>
><br>
> If you move a `unique_ptr` into a lambda,
that doesn't mean you're going to<br>
> modify the `unique_ptr` *itself*. You may
modify what it points to, but<br>
> `unique_ptr` doesn't forward `const`
through to `get`.<br>
>><br>
>> Also, do you really want to move from
`x`?<br>
>><br>
>> I really do want to move from x. I have
thousands of lines doing that,<br>
>> though I expect a significant reduction
when we start using coroutines.<br>
><br>
><br>
> My question is why do you want to move
there instead of decay-copying?<br>
<br>
My impression is that DECAY_COPY(x) always gives
you a brand-new object (that is, it literally
does move the representation of x from one
address to another), whereas std::move(x) always
gives you a reference (generally an rvalue
reference) that usually doesn't require any
extra codegen.
<div><br>
</div>
<div>I strongly suspect that when Avi is
concerned with "move-only and mutable" =
types,
being captured by lambdas, potentially
replaceable with coroutines, the <i>specific</i>
types he's thinking about are std::promise
and/or std::future. Using promises and futures
with lambdas really <i>does</i> require a lot
of noisy "mutable" keywords; his use-ca=
se is
valid.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Yes, future and promise (in the seastar namespace,
not std, but same usage). Usually it's not the
future/promise types that are moved, but state
needed for continuations.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>But I don't want to see "implicit mut=
able"
in the language at this point, either. I'm
certain that "mutable" should have been=
the
default in 2011, but now that ship has been
sailed for 6 years; we can't get it back.</di=
v>
<div><br>
</div>
</div>
</blockquote>
<br>
Not even for capture-by-move variable? Not the
entire lambda. It's likely that most lambdas that
have a capture-by-move will also be mutable.<br>
</div>
</blockquote>
<div><br>
I would like to see some evidence for that statement.
You're talking about overturning a basic aspect of
lambdas since they were standardized in 2011. It's no=
t
something that we should just do willy nilly.<br>
<br>
</div>
</div>
</blockquote>
Here's one sample:<br>
<br>
$ git grep -E '\[.*=3D.*std::move.*\]' | wc -l<br>
319<br>
$ git grep -E '\[.*=3D.*std::move.*\].*<wbr>mutable' | =
wc -l<br>
142<br>
<br>
So, about half. The ones that don't have mutable are either
the last continuation in the chain (so don't need to be
moved out), or just performance bugs - the move gets
converted into a copy.<br>
</div>
</blockquote>
<div><br>
You made a very general statement: "It's likely that mos=
t
lambdas that have a capture-by-move will also be mutable."
That statement did not limit itself to code you're responsibl=
e
for. So do you have evidence that this is true of C++ code in
general?<br>
</div>
</div>
</blockquote>
<br>
Unfortunately, I do not.<br>
<br>
The style of code used in my example, while not very common, is also
not specific to my application. So I expect my code would not be the
only beneficiary.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>I have a strong dislike for the idea that `[x =3D
std::move(x)]` should in any way be different from
`[&&x]`. There needs to be a <i>really</i>
good reason for doing that.</div>
</div>
</blockquote>
<br>
The reason is, by making the lambda the owner of the
contents, you're no longer protecting the original object
from missing a mutation.<br>
</div>
</blockquote>
<div><br>
But <i>both of them</i> are making the lambda "the owner of
the contents". My question is why should one way of
transferring ownership be different from the other?<br>
</div>
</div>
</blockquote>
<br>
Because one way is set in stone and cannot be modified. The other
way can still be changed, and it should be chosen to fit the user's
needs, not an overriding sense of consistency. Consistency is good,
but it's not something that C++ will be good at. I'm not propos=
ing
that we should ignore it, just that it should not be the top
priority.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> By forcing the user to
make the entire lambda mutable, you're reducing the ability
to detect this kind of bug on variables that _are_ copied by
value.<br>
</div>
</blockquote>
<div><br>
I don't know what you mean by that. Your original declaration
was that the use of `&&x` in a capture list causes the
lambda to become `mutable`:<br>
<br>
> I would like to re-raise [&&x] as a shortcut for
[x =3D std::move(x)] () mutable.<br>
<br>
Are you now saying that you want it to be limited to just `x`
being `mutable`? Wouldn't it make more sense to just allow yo=
u
to do this `[mutable &&x]`, `[mutable x =3D
std::move(x)]` and so forth?<br>
</div>
</div>
</blockquote>
<br>
I changed my position a few emails ago, you must have missed it.<br>
<br>
I do like [mutable x], but it will be rare. [mutable &&x] on
the other hand will be very common, and on many occasions forgetting
it will be a subtle mistake (for copy/move types) or a compile error
(for move-only types) so to remove this class of error it should be
the default.<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
Why should mutability be tied to how the capture variable was
initialized? These are entirely orthogonal constructs, so they
should be handled with orthogonal syntax.<br>
</div>
</div>
<br>
</blockquote>
<br>
Because, for copy capture, const is the sensible bug-preventing
default, while for move-capture, mutable is the sensible
bug-preventing default.<br>
<br>
</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/2aff507c-b712-413a-b8d2-495e1533e96f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2aff507c-b712-413a-b8d2-495e1533e96f=
%40isocpp.org</a>.<br />
------=_Part_189_1061616845.1503530960385--
------=_Part_188_1054843487.1503530960384--
.