------=_Part_2138_123544281.1429452362233
Content-Type: multipart/alternative;
 boundary="----=_Part_2139_1939527765.1429452362234"

------=_Part_2139_1939527765.1429452362234
Content-Type: text/plain; charset=UTF-8

Lambdas currently support three styles of capture:

1. Init capture (fully generic) [x = expression]
2. Copy capture: [x], equivalent to [x = x]
3. Reference capture: [&x], roughly equivalent to [x = std::ref(x)]

As I find myself typing [x = std::move(x)] more and more, I propose to
support a fourth style:

4. Move capture: [&&x], equivalent to [x = std::move(x)]

This would be very useful for move-only types such as unique_ptr<>.

(the idea has been proposed before on the comp.std.c++ newsgroup)


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Lambdas currently support three styles of capture:<div><br=
></div><div>1. Init capture (fully generic) [x =3D expression]</div><div>2.=
 Copy capture: [x], equivalent to [x =3D x]</div><div>3. Reference capture:=
 [&amp;x], roughly equivalent to [x =3D std::ref(x)]</div><div><br></div><d=
iv>As I find myself typing [x =3D std::move(x)] more and more, I propose to=
 support a fourth style:</div><div><br></div><div>4. Move capture: [&amp;&a=
mp;x], equivalent to [x =3D std::move(x)]</div><div><br></div><div>This wou=
ld be very useful for move-only types such as unique_ptr&lt;&gt;.</div><div=
><br></div><div>(the idea has been proposed before on the comp.std.c++ news=
group)<br><div><br></div><div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2139_1939527765.1429452362234--
------=_Part_2138_123544281.1429452362233--

.

On 19 April 2015 at 17:06, Avi Kivity <avi@cloudius-systems.com> wrote:
> Lambdas currently support three styles of capture:
>
> 1. Init capture (fully generic) [x = expression]
> 2. Copy capture: [x], equivalent to [x = x]
> 3. Reference capture: [&x], roughly equivalent to [x = std::ref(x)]
>
> As I find myself typing [x = std::move(x)] more and more, I propose to
> support a fourth style:
>
> 4. Move capture: [&&x], equivalent to [x = std::move(x)]
>
> This would be very useful for move-only types such as unique_ptr<>.


I don't see that as a good idea. It looks like a
capture-by-rvalue-reference, but
you don't want to capture an rvalue reference, you want to capture a
value initialized
from an rvalue. Consistently, when you want to move into a function or
into a constructor,
you need to use std::move. For a lambda, you're initializing a
capture, which is rather
similar to calling a constructor, so using std::move there makes sense.

This syntax has been proposed in the committee too - we found it undesirable
due to the points above, and went for init-captures since they can do much more
than initialize from an rvalue.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 04/19/2015 05:26 PM, Ville Voutilainen wrote:
> On 19 April 2015 at 17:06, Avi Kivity <avi@cloudius-systems.com> wrote:
>> Lambdas currently support three styles of capture:
>>
>> 1. Init capture (fully generic) [x = expression]
>> 2. Copy capture: [x], equivalent to [x = x]
>> 3. Reference capture: [&x], roughly equivalent to [x = std::ref(x)]
>>
>> As I find myself typing [x = std::move(x)] more and more, I propose to
>> support a fourth style:
>>
>> 4. Move capture: [&&x], equivalent to [x = std::move(x)]
>>
>> This would be very useful for move-only types such as unique_ptr<>.
>
> I don't see that as a good idea. It looks like a
> capture-by-rvalue-reference, but
> you don't want to capture an rvalue reference, you want to capture a
> value initialized
> from an rvalue. Consistently, when you want to move into a function or
> into a constructor,
> you need to use std::move. For a lambda, you're initializing a
> capture, which is rather
> similar to calling a constructor, so using std::move there makes sense.
>
> This syntax has been proposed in the committee too - we found it undesirable
> due to the points above, and went for init-captures since they can do much more
> than initialize from an rvalue.

Well, it's a pity.  In a not-so-large code base I have about 100
instances of this pattern, some with multiple variables move-captured in
the same lambda.  This syntax would greatly reduce verbosity for a very
repetitive pattern.

But I appreciate the subtle different between &x and &&x (clobbering of
the source).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.