2013/6/5 Mikhail Semenov <mikhailsemenov1957@gmail.com>:
> I wonder if there is a chance to get it expicitly stated in the standard
> that, in  cases like the one below, the move constructor (or even higher
> optimization, like re-use) should be used (not the copy constructor):

It is unclear which copy/move constructor you are referring to. A
copy/move constructor of the vector or of the lambda closure? If of
the vector, do you mean it should be invoked when captured or during
the closure return statement? In the following I assume you mean that
of the vector and you mean the return statement of the closure.

Second, assuming I understood your request correctly, this has not
anything to do with optimization, it would be a fundamental core
language change and I would expect that to be controversial (see below
why). What the language allows you since the Bristol meeting is to
support "expression captures" (normative wording denotes them as
"init-capture"), so you can indeed rewrite the lambda expression now
to

auto f()
{
    double a[] = {0.1, 2.0, 3.5};
    std::vector<double>v1(a,a+3);
    return [v1 = std::move(v1)](){ return v1; };    // use move (or
re-use) not copy
}

The effect is that now the local variable v1 is moved into a data
member of the closure named v1 within the scope of the lambda
expression.

> auto f()
> {
>     double a[] = {0.1, 2.0, 3.5};
>     std::vector<double>v1(a,a+3);
>     return [v1](){ return v1; };    // use move (or re-use) not copy
> }
>
> I have noticed that some developers started writing their own captures,
> which explicitly use move.
> At the same time, some compilers (like Visual C++) already provide
> optimization.
> I think the users should not re-invent the wheel.

It all depends what precisely you mean. If you mean the compiler
should move the v1 capture in your example code during the return
statement of the closure I'm strongly opposed to such a change: A
closure is a function object that can potentially be called multiple
times. If it would move the *own* member (and not some local variable
with automatic storage duration), this would violate the model of RVO
and it would lead to a lot of surprises for the user of that code.

- Daniel

--

---
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/?hl=en.



.

------=_Part_4978_25171160.1370431581430
Content-Type: text/plain; charset=ISO-8859-1

I think that he wants to implicitly move the local variable into the
lambda. This I support, as I think that the language can easily specify the
limited and known correct situations under which this can occur.

--

---
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/?hl=en.



------=_Part_4978_25171160.1370431581430
Content-Type: text/html; charset=ISO-8859-1

I think that he wants to implicitly move the local variable into the lambda. This I support, as I think that the language can easily specify the limited and known correct situations under which this can occur.

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4978_25171160.1370431581430--

.

2013/6/5 DeadMG <wolfeinstein@gmail.com>:
> I think that he wants to implicitly move the local variable into the lambda.
> This I support, as I think that the language can easily specify the limited
> and known correct situations under which this can occur.

I disagree with that being a good change. RVO applies to situations
where we have a clear "exit" channel and after which the affected
object is "history". But this isn't provided for situations where
expressions or variables are captured by a closure. IMO the new
init-captures that I have presented for this case

return [v1 = std::move(v1)](){ return v1; };

allow to support this request without leading to unexpected gotchas in
the code parts following the closure construction.

- Daniel

[P.S. Please quote a minimum of the message that you are responding
to. In 80% of your replies I don't understand to *what* or to "whom*
you reply]

--

---
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/?hl=en.



.

------=_Part_3938_23938225.1370432908926
Content-Type: text/plain; charset=ISO-8859-1

Daniel,

>return [v1 = std::move(v1)](){ return v1; };

This will work, as I wanted it to.

My point is that
*return [v1 = std::move(v1)](){ return v1; }; *
should be equivalent to this
 *return [v1](){ return v1; }; *
when v1 is a local variable.

>It all depends what precisely you mean. If you mean the compiler
>should move the v1 capture in your example code during the return
>statement of the closure I'm strongly opposed to such a change: A
>closure is a function object that can potentially be called multiple
>times. If it would move the *own* member (and not some local variable
>with automatic storage duration), this would violate the model of RVO
>and it would lead to a lot of surprises for the user of that code.

But I meant only in case when the local variable is at the end of its
existence,
(there is no member variable!). There no surprises here:

*The lambda captures the local variable and is returned from the block.*
*I mean when the variable is captured by lambda ([v1]()...): move should be
done, not copy**.*
**
Sorry for the confusion.

Mikhail.
**
**




--

---
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/?hl=en.



------=_Part_3938_23938225.1370432908926
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<DIV>Daniel,</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#351c75><FONT color=3D#9900ff>&gt;return [v1 =3D std::mo=
ve(v1)](){ return v1; };</FONT> </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>This will work, as I wanted it to. </DIV>
<DIV>&nbsp;</DIV>
<DIV>My point is that </DIV>
<DIV><STRONG><FONT color=3D#000000>return [v1 =3D std::move(v1)](){ return =
v1; }; </FONT></STRONG></DIV>
<DIV><FONT color=3D#000000>should be equivalent to this</FONT></DIV>
<DIV>
<DIV><STRONG><FONT color=3D#000000>return [v1](){ return v1; }; </FONT></ST=
RONG></DIV>
<DIV><FONT color=3D#000000>when v1 is a local variable.</FONT></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#9900ff>&gt;It all depends what precisely you mean. If y=
ou mean the compiler <BR>&gt;should move the v1 capture in your example cod=
e during the return <BR>&gt;statement of the closure I'm strongly opposed t=
o such a change: A <BR>&gt;closure is a function object that can potentiall=
y be called multiple <BR>&gt;times. If it would move the *own* member (and =
not some local variable <BR>&gt;with automatic storage duration), this woul=
d violate the model of RVO <BR>&gt;and it would lead to a lot of surprises =
for the user of that code. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>But I meant only in case when the local variable is at the end of its =
existence,</DIV>
<DIV>(there is no member variable!). There no surprises here:</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>The lambda captures the local variable and is returned from th=
e block.</STRONG></DIV>
<DIV><STRONG>I mean when the variable is captured by lambda ([v1]()...): mo=
ve should be done, not copy</STRONG><STRONG>.</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV>Sorry for the confusion.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Mikhail.</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3938_23938225.1370432908926--

.

------=_Part_6188_26486923.1370433108479
Content-Type: text/plain; charset=ISO-8859-1


>
> RVO applies to situations where we have a clear "exit" channel


We have a clear exit channel- into the lambda.

 and after which the affected object is "history".


Since it is a local variable, this applies just as much to trying to put it
in a lambda as trying to put it anywhere else, really.

unexpected gotchas in the code parts following the closure construction.


There are no code parts following the closure construction, since it is a
return statement.

Frankly, I don't understand why the Standard does not permit RVO anywhere
the compiler can prove it under as-if, where a move is seen as a valid
as-if optimization of a copy, and all copy and move constructors are
considered elidable in all scenarios that the compiler can prove. But
that's a story for another day, perhaps. The lambda deal should certainly
be available within the existing philosophy.

--

---
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/?hl=en.



------=_Part_6188_26486923.1370433108479
Content-Type: text/html; charset=ISO-8859-1
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;">RVO applies to situations where we have a clea=
r "exit" channel</blockquote><div><br></div><div>We have a clear exit chann=
el- into the lambda.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-col=
or: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">&nbsp=
;and after which the affected object is "history".</blockquote><div><br></d=
iv><div>Since it is a local variable, this applies just as much to trying t=
o put it in a lambda as trying to put it anywhere else, really.</div><div><=
br></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bor=
der-left-style: solid; padding-left: 1ex;">unexpected gotchas in the code p=
arts following the closure construction.</blockquote><div><br></div><div>Th=
ere are no code parts following the closure construction, since it is a ret=
urn statement.</div></div><div><br></div><div>Frankly, I don't understand w=
hy the Standard does not permit RVO anywhere the compiler can prove it unde=
r as-if, where a move is seen as a valid as-if optimization of a copy, and =
all copy and move constructors are considered elidable in all scenarios tha=
t the compiler can prove. But that's a story for another day, perhaps. The =
lambda deal should certainly be available within the existing philosophy.</=
div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6188_26486923.1370433108479--

.

------=_Part_6754_1362665.1370433732955
Content-Type: text/plain; charset=ISO-8859-1


>
> Daniel,


I support DeadMG on this: clear cases of optimization should be properly
stated in the standard: the same as with local return from a block (when
move is done). Otherwise, we may get unexpected surprises in cases
of cross-compilation, when some compilers don't optimise the code properly
and use a copy in the above-mentioned case.

Mikhail.


--

---
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/?hl=en.



------=_Part_6754_1362665.1370433732955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>Daniel,</BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>I support DeadMG on this: clear cases of optimization should be proper=
ly stated in the standard: the same as with local return from a block (when=
 move is done). Otherwise, we may get unexpected surprises&nbsp;in cases of=
&nbsp;cross-compilation, when some compilers don't optimise the code proper=
ly and use a copy in the above-mentioned case.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Mikhail.</DIV>
<DIV>&nbsp;</DIV>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6754_1362665.1370433732955--

.

2013/6/5 Mikhail Semenov <mikhailsemenov1957@gmail.com>:
> Daniel,
>
>>return [v1 = std::move(v1)](){ return v1; };
>
> This will work, as I wanted it to.
>
> My point is that
> return [v1 = std::move(v1)](){ return v1; };
> should be equivalent to this
> return [v1](){ return v1; };
> when v1 is a local variable.

Thanks for clarification. As I responded to DeadMG, I would be opposed
to such a change. Implicit move operations are fine in situations
where the moved object is no longer of interest. This is OK in a
function return statement acting on a variable with automatic storage
duration. It is (in general) *not* OK when constructing a closure
object, because this might just be one part of the operations within
that function and the following code could validly refer to v1 again.
I this situation an *implicit* move would be very contrary to the
general behaviour of C++ and it would have possibly surprising effects
on the rest of the code within this function.

- Daniel

--

---
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/?hl=en.



.

--001a11332fea7b946104de6700df
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 14:51, DeadMG <wolfeinstein@gmail.com> wrote:

> RVO applies to situations where we have a clear "exit" channel
>
>
> We have a clear exit channel- into the lambda.
>

Except for cases where the local variable is passed elsewhere in addition
to the lambda.

--

---
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/?hl=en.



--001a11332fea7b946104de6700df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 14:51, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><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">
RVO applies to situations where we have a clear &quot;exit&quot; channel</b=
lockquote><div><br></div></div><div>We have a clear exit channel- into the =
lambda.</div></blockquote><div><br></div><div>Except for cases where the lo=
cal variable is passed elsewhere in addition to the lambda.<br>
=A0<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11332fea7b946104de6700df--

.

------=_Part_317_2947423.1370435012068
Content-Type: text/plain; charset=ISO-8859-1

The proposed change would allow this to compile:

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  return [p]{ return *p; };
}

but it would fail to compile if slightly modified:

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  auto lambda = [p]{ return *p; };
  std::cout << "loggity loggity log\n";
  return lambda;
}

The difference is a bit subtle and could be confusing.

--

---
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/?hl=en.



------=_Part_317_2947423.1370435012068
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The proposed change would allow this to compile:<br><br>std::function&lt;in=
t()&gt; func()<br>{<br>&nbsp; auto p =3D std::make_unique&lt;int&gt;();<br>=
&nbsp; return [p]{ return *p; };<br>}<br><br>but it would fail to compile i=
f slightly modified:<br><br>std::function&lt;int()&gt; func()<br>{<br>&nbsp=
; auto p =3D std::make_unique&lt;int&gt;();<br>&nbsp; auto lambda =3D [p]{ =
return *p; };<br>&nbsp; std::cout &lt;&lt; "loggity loggity log\n";<br>&nbs=
p; return lambda;<br>}<br><br>The difference is a bit subtle and could be c=
onfusing.<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_317_2947423.1370435012068--

.

------=_Part_34_7829672.1370435352013
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 5, 2013 1:23:32 PM UTC+1, Jonathan Wakely wrote:
>
> The proposed change would allow this to compile:
>
> std::function<int()> func()
> {
>   auto p = std::make_unique<int>();
>   return [p]{ return *p; };
> }
>
> but it would fail to compile if slightly modified:
>
> std::function<int()> func()
> {
>   auto p = std::make_unique<int>();
>   auto lambda = [p]{ return *p; };
>   std::cout << "loggity loggity log\n";
>   return lambda;
> }
>
> The difference is a bit subtle and could be confusing.
>

That's an extreme example where the change causes it to fail to compile, a
nastier example would be where the captured variable is both copyable and
movable, and the change introduces a performance hit because a move
silently becomes an expensive copy.  The explicit [p = std::move(p)]
capture avoids that problem.

I'm not sure this problem should skupper the proposal, but I find it
concerning.

--

---
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/?hl=en.



------=_Part_34_7829672.1370435352013
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 5, 2013 1:23:32 PM UTC+1, Jonathan Wakely wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">The proposed change would allo=
w this to compile:<br><br>std::function&lt;int()&gt; func()<br>{<br>&nbsp; =
auto p =3D std::make_unique&lt;int&gt;();<br>&nbsp; return [p]{ return *p; =
};<br>}<br><br>but it would fail to compile if slightly modified:<br><br>st=
d::function&lt;int()&gt; func()<br>{<br>&nbsp; auto p =3D std::make_unique&=
lt;int&gt;();<br>&nbsp; auto lambda =3D [p]{ return *p; };<br>&nbsp; std::c=
out &lt;&lt; "loggity loggity log\n";<br>&nbsp; return lambda;<br>}<br><br>=
The difference is a bit subtle and could be confusing.<br></blockquote><div=
><br>That's an extreme example where the change causes it to fail to compil=
e, a nastier example would be where the captured variable is both copyable =
and movable, and the change introduces a performance hit because a move sil=
ently becomes an expensive copy.&nbsp; The explicit [p =3D std::move(p)] ca=
pture avoids that problem.<br><br>I'm not sure this problem should skupper =
the proposal, but I find it concerning.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_34_7829672.1370435352013--

.

------=_Part_3929_24268775.1370436236282
Content-Type: text/plain; charset=ISO-8859-1

My view on this is that the use std::move should be avoided as much as
possible to avoid complexity of the code, except in cases when you
explicitly
use rvalue references: T&& (usually in parameters).  As I mentioned before,
we already deal with cases of "implicit" move when a local variable is
returned as a value of the function; why not do it here?


--

---
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/?hl=en.



------=_Part_3929_24268775.1370436236282
Content-Type: text/html; charset=ISO-8859-1

<DIV>My view on this is that the use std::move should be avoided as much as possible to avoid complexity of the code, except in cases when you explicitly</DIV>
<DIV>use rvalue references: T&amp;&amp; (usually in parameters).&nbsp; As I mentioned before, we already deal with cases of "implicit" move when a local variable is returned as a value of the function; why not do it here?</DIV>
<DIV>&nbsp;</DIV>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3929_24268775.1370436236282--

.

------=_Part_353_15295987.1370441399010
Content-Type: text/plain; charset=ISO-8859-1


>
> it would fail to compile if slightly modified:


We already have an identical situation with function return values.

std::unique_ptr<int> f(std::unique_ptr<int> in) { return in; }
std::unique_ptr<int> func() {
    auto p = std::make_unique<int>();
    return p; // Fine

    auto var = p;
    std::cout << "loggity loggity log\n";
    return var; // Not fine.
}

When dealing with move-only types this is just one of the things you have
to deal with. In both cases you can always use an explicit std::move.

Except for cases where the local variable is passed elsewhere in addition
> to the lambda.


It's gonna be UB for them to access that variable after the lambda is
constructed and the function returns, and they can't access it whilst the
lambda is being constructed because, y'know, the lambda is of a strict form
which does not permit that. In the example

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  f(p); // assume reference, say
  return [p]{ return *p; };
}

There is no way for anyone to legally access p during or after the lambda's
construction. The lambda code obviously does not do so (and including
something that does would obviously fall outside the remit of the
proposal), and anyone accessing it through an alias after the lambda is
constructed is already in UB-land because the function has returned before
any more user-defined code can execute. But finally, again, there is no
difference here between "Move p into return value" and "Move p into lambda
and move lambda into return value". If you want to suggest that there is,
perhaps you should provide a code sample which shows some bad behaviour,
because as far as I can tell, it is strictly limited such that that is
impossible, just like the existing implicit move.

--

---
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/?hl=en.



------=_Part_353_15295987.1370441399010
Content-Type: text/html; charset=ISO-8859-1
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;">it would fail to compile if slightly modified:=
</blockquote><div><br></div><div>We already have an identical situation wit=
h function return values.</div><div><br></div><div>std::unique_ptr&lt;int&g=
t; f(std::unique_ptr&lt;int&gt; in) { return in; }</div><div>std::unique_pt=
r&lt;int&gt; func() {</div><div>&nbsp; &nbsp; auto p =3D std::make_unique&l=
t;int&gt;();</div><div>&nbsp; &nbsp; return p; // Fine</div><div><br></div>=
<div>&nbsp; &nbsp; auto var =3D p;</div><div>&nbsp; &nbsp; std::cout &lt;&l=
t; "loggity loggity log\n";</div><div>&nbsp; &nbsp; return var; // Not fine=
..</div><div>}</div><div><br></div><div>When dealing with move-only types th=
is is just one of the things you have to deal with. In both cases you can a=
lways use an explicit std::move.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
 1ex;">Except for cases where the local variable is passed elsewhere in add=
ition to the lambda.</blockquote><div><br></div><div>It's gonna be UB for t=
hem to access that variable after the lambda is constructed and the functio=
n returns, and they can't access it whilst the lambda is being constructed =
because, y'know, the lambda is of a strict form which does not permit that.=
 In the example</div><div><br></div>std::function&lt;int()&gt; func()<br>{<=
br>&nbsp; auto p =3D std::make_unique&lt;int&gt;();<div>&nbsp; f(p); // ass=
ume reference, say<br>&nbsp; return [p]{ return *p; };<br><div>}</div><div>=
<br></div><div>There is no way for anyone to legally access p during or aft=
er the lambda's construction. The lambda code obviously does not do so (and=
 including something that does would obviously fall outside the remit of th=
e proposal), and anyone accessing it through an alias after the lambda is c=
onstructed is already in UB-land because the function has returned before a=
ny more user-defined code can execute. But finally, again, there is no diff=
erence here between "Move p into return value" and "Move p into lambda and =
move lambda into return value". If you want to suggest that there is, perha=
ps you should provide a code sample which shows some bad behaviour, because=
 as far as I can tell, it is strictly limited such that that is impossible,=
 just like the existing implicit move.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_353_15295987.1370441399010--

.

------=_Part_79_8096823.1370443485377
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 5, 2013 3:09:59 PM UTC+1, DeadMG wrote:
>
> it would fail to compile if slightly modified:
>
>
> We already have an identical situation with function return values.
>
> std::unique_ptr<int> f(std::unique_ptr<int> in) { return in; }
> std::unique_ptr<int> func() {
>     auto p = std::make_unique<int>();
>     return p; // Fine
>
>     auto var = p;
>

This line would fail, not the return.


>     std::cout << "loggity loggity log\n";
>     return var; // Not fine.
> }
>

[...]


> But finally, again, there is no difference here between "Move p into
> return value" and "Move p into lambda and move lambda into return value".
>

I disagree, they're not the same.

Why should lambdas be special? If it works for lambdas it would work here
too:

int deref(std::unique_ptr<int> p) { return *p; }

int func()
{
  auto p = std::make_unique<int>();
  return deref(p);
}

Or:

struct A { std::unique_ptr<int> p; };

A func()
{
  auto p = std::make_unique<int>();
  return { p };
}


Can we please stop trying to squeeze every possible language feature into
lambdas?
Not everything can or should be done with lambdas, especially if it makes
the rest of the language into second-class citizens.

--

---
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/?hl=en.



------=_Part_79_8096823.1370443485377
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 5, 2013 3:09:59 PM UTC+1, DeadMG wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">it would fail to compi=
le if slightly modified:</blockquote><div><br></div><div>We already have an=
 identical situation with function return values.</div><div><br></div><div>=
std::unique_ptr&lt;int&gt; f(std::unique_ptr&lt;int&gt; in) { return in; }<=
/div><div>std::unique_ptr&lt;int&gt; func() {</div><div>&nbsp; &nbsp; auto =
p =3D std::make_unique&lt;int&gt;();</div><div>&nbsp; &nbsp; return p; // F=
ine</div><div><br></div><div>&nbsp; &nbsp; auto var =3D p;</div></blockquot=
e><div><br>This line would fail, not the return.<br>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div>&nbsp; &nbsp; std::cout &lt;&lt; "lo=
ggity loggity log\n";</div><div>&nbsp; &nbsp; return var; // Not fine.</div=
><div>}</div><div></div></blockquote><div><br>[...]<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>But finally, again, there is no d=
ifference here between "Move p into return value" and "Move p into lambda a=
nd move lambda into return value".</div></blockquote><div><br>I disagree, t=
hey're not the same.<br><br>Why should lambdas be special? If it works for =
lambdas it would work here too:<br><br>int deref(std::unique_ptr&lt;int&gt;=
 p) { return *p; }<br><br>int func()<br>{<br>&nbsp; auto p =3D std::make_un=
ique&lt;int&gt;();<br>&nbsp; return deref(p);<br>}<br><br>Or:<br><br>struct=
 A { std::unique_ptr&lt;int&gt; p; };<br><br>A func()<br>{<br>&nbsp; auto p=
 =3D std::make_unique&lt;int&gt;();<br>&nbsp; return { p };<br>}<br><br><br=
>Can we please stop trying to squeeze every possible language feature into =
lambdas?<br>Not everything can or should be done with lambdas, especially i=
f it makes the rest of the language into second-class citizens.<br><br></di=
v>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_79_8096823.1370443485377--

.

--14dae9c09c1e534dc604de6955fb
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 17:09, DeadMG <wolfeinstein@gmail.com> wrote:

> Except for cases where the local variable is passed elsewhere in addition
> to the lambda.
>
> It's gonna be UB for them to access that variable after the lambda is
> constructed and the function returns, and they can't access it whilst the
> lambda is being constructed because, y'know, the lambda is of a strict form
> which does not permit that. In the example
>
> std::function<int()> func()
> {
>   auto p = std::make_unique<int>();
>   f(p); // assume reference, say
>   return [p]{ return *p; };
> }
>
>
>
Sure. But do you think it should be different to have

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  return [p]{ return *p; };
}

in contrast to

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  auto x = [p]{ return *p; };
  return x;
}

and then

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  auto x = [p]{ return *p; };
  f(p);
  return x;
}

The difference between the first case and the others is quite subtle.

--

---
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/?hl=en.



--14dae9c09c1e534dc604de6955fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 17:09, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Except for cases where th=
e local variable is passed elsewhere in addition to the lambda.<div class=
=3D"im">
<div><br></div></div><div>It&#39;s gonna be UB for them to access that vari=
able after the lambda is constructed and the function returns, and they can=
&#39;t access it whilst the lambda is being constructed because, y&#39;know=
, the lambda is of a strict form which does not permit that. In the example=
</div>
<div class=3D"im"><div><br></div>std::function&lt;int()&gt; func()<br>{<br>=
=A0 auto p =3D std::make_unique&lt;int&gt;();</div><div>=A0 f(p); // assume=
 reference, say<br>=A0 return [p]{ return *p; };<br><div>}</div><div><br><b=
r></div>
</div></blockquote><div><br></div><div>Sure. But do you think it should be =
different to have<br><br>std::function&lt;int()&gt; func()<br>{<br>=A0 auto=
 p =3D std::make_unique&lt;int&gt;();<br>=A0 return [p]{ return *p; };<br><=
div>
}</div><br></div><div>in contrast to<br></div></div><br>std::function&lt;in=
t()&gt; func()<br>{<br>=A0 auto p =3D std::make_unique&lt;int&gt;();<br>=A0=
 auto x =3D [p]{ return *p; };<br></div><div class=3D"gmail_extra">=A0 retu=
rn x;<br>
</div><div class=3D"gmail_extra"><div>}</div><br></div><div class=3D"gmail_=
extra">and then<br><br>std::function&lt;int()&gt; func()<br>{<br>=A0 auto p=
 =3D std::make_unique&lt;int&gt;();<br>=A0 auto x =3D [p]{ return *p; };<br=
></div><div class=3D"gmail_extra">
=A0 f(p);<br></div><div class=3D"gmail_extra"><div class=3D"gmail_extra">=
=A0 return x;<br></div><div class=3D"gmail_extra"><div>}</div><br></div>The=
 difference between the first case and the others is quite subtle.<br></div=
></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9c09c1e534dc604de6955fb--

.

------=_Part_2103_4985908.1370444549302
Content-Type: text/plain; charset=ISO-8859-1


>
> Why should lambdas be special? If it works for lambdas it would work here
> too


Because the language guarantees what is going to happen. If you have
`deref(p)`, the compiler cannot know that moving p is safe. After all,
deref might use a global variable, set earlier, that happens to alias p,
and if the content of p were to magically disappear, this would break the
user's code. On the other hand, it can do this when moving into a lambda
because the language guarantees the consequences of constructing a lambda
and the elision rules for move and copy constructors gives us the freedom
to ignore such aliases. Nobody can write their move constructor to depend
on global aliases to their objects, because we already elide them in other
contexts. deref is another matter. I think that arguably, we could have an
attribute that would permit deref(p), and I think we should widen the scope
of elision, but that's beyond the scope of this discussion. The simple fact
is that the move/copy constructors have different semantics to just any
arbitrary user function.

And also, this doesn't make lambdas special, it makes them the same. It
brings them in line with what we already do. We can have the requisite
guarantees about move and copy constructors in this case, so it should be
legal for the compiler to elide and required for them to implicitly move,
just like in every other place we can have those guarantees.

 This line would fail, not the return.


Yeah, I made a slight labelling mistake there, but my sample and Jonathan's
sample both fail at exactly the same line, and for exactly the same reason-
unique_ptr is move only so you can't prepare the return value ahead of the
return statement if you wish to use an implicit move. This is just as true
for returning a unique_ptr directly right now as it is for returning a
lambda containing a unique_ptr if this proposal were accepted.

Sure. But do you think it should be different to have


Replace [p] { return *p; } with p, and you have exactly the same issues.
This doesn't bring anything new to the table.

--

---
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/?hl=en.



------=_Part_2103_4985908.1370444549302
Content-Type: text/html; charset=ISO-8859-1
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;">Why should lambdas be special? If it works for=
 lambdas it would work here too</blockquote><div><br></div><div>Because the=
 language guarantees what is going to happen. If you have `deref(p)`, the c=
ompiler cannot know that moving p is safe. After all, deref might use a glo=
bal variable, set earlier, that happens to alias p, and if the content of p=
 were to magically disappear, this would break the user's code. On the othe=
r hand, it can do this when moving into a lambda because the language guara=
ntees the consequences of constructing a lambda and the elision rules for m=
ove and copy constructors gives us the freedom to ignore such aliases. Nobo=
dy can write their move constructor to depend on global aliases to their ob=
jects, because we already elide them in other contexts. deref is another ma=
tter. I think that arguably, we could have an attribute that would permit d=
eref(p), and I think we should widen the scope of elision, but that's beyon=
d the scope of this discussion. The simple fact is that the move/copy const=
ructors have different semantics to just any arbitrary user function.</div>=
<div><br></div><div>And also, this doesn't make lambdas special, it makes t=
hem the same. It brings them in line with what we already do. We can have t=
he requisite guarantees about move and copy constructors in this case, so i=
t should be legal for the compiler to elide and required for them to implic=
itly move, just like in every other place we can have those guarantees.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">&nbsp;This line would fail, n=
ot the return.</blockquote><div><br></div><div>Yeah, I made a slight labell=
ing mistake there, but my sample and Jonathan's sample both fail at exactly=
 the same line, and for exactly the same reason- unique_ptr is move only so=
 you can't prepare the return value ahead of the return statement if you wi=
sh to use an implicit move. This is just as true for returning a unique_ptr=
 directly right now as it is for returning a lambda containing a unique_ptr=
 if this proposal were accepted.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
 1ex;">Sure. But do you think it should be different to have</blockquote><d=
iv><br></div><div>Replace [p] { return *p; } with p, and you have exactly t=
he same issues. This doesn't bring anything new to the table.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2103_4985908.1370444549302--

.

--20cf303b39f1da86ad04de69a8f3
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 18:02, DeadMG <wolfeinstein@gmail.com> wrote:

>
> Sure. But do you think it should be different to have
>
>
> Replace [p] { return *p; } with p, and you have exactly the same issues.
> This doesn't bring anything new to the table.
>
>
>
>
No I don't. If I return p;, it'll always move, and it'll never move
surreptitiously before I call other functions, whereas
an automatic move-capture in a lambda that's not immediately returned will
do precisely 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--20cf303b39f1da86ad04de69a8f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 18:02, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_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">
Sure. But do you think it should be different to have</blockquote><div><br>=
</div></div><div>Replace [p] { return *p; } with p, and you have exactly th=
e same issues. This doesn&#39;t bring anything new to the table.</div><div =
class=3D"HOEnZb">
<div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>No I don&#39;t. If I r=
eturn p;, it&#39;ll always move, and it&#39;ll never move surreptitiously b=
efore I call other functions, whereas<br>an automatic move-capture in a lam=
bda that&#39;s not immediately returned will do precisely that. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf303b39f1da86ad04de69a8f3--

.

------=_Part_2002_2869055.1370445365937
Content-Type: text/plain; charset=ISO-8859-1

You cannot call other functions between the move and the return. How could
that possibly be done? The language guarantees that if you create a lambda,
the contents will be copied (now moved), then you return. What could you
possibly do to access the local variable after the move but before the
return?

--

---
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/?hl=en.



------=_Part_2002_2869055.1370445365937
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You cannot call other functions between the move and the return. How could =
that possibly be done? The language guarantees that if you create a lambda,=
 the contents will be copied (now moved), then you return. What could you p=
ossibly do to access the local variable after the move but before the retur=
n?

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2002_2869055.1370445365937--

.

------=_Part_2110_24920244.1370445396169
Content-Type: text/plain; charset=ISO-8859-1

Er, if you return a lambda. I obviously don't mean for some arbitrary
lambda creation.

--

---
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/?hl=en.



------=_Part_2110_24920244.1370445396169
Content-Type: text/html; charset=ISO-8859-1

Er, if you return a lambda. I obviously don't mean for some arbitrary lambda creation.

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2110_24920244.1370445396169--

.

--14dae9c09c1eb3003b04de69b9fe
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 18:16, DeadMG <wolfeinstein@gmail.com> wrote:

> Er, if you return a lambda. I obviously don't mean for some arbitrary
> lambda creation.
>
>
>
>
"Obviously". That's why I asked whether you really want [p] to mean move
capture in
some situations, and copy-capture in others, depending on the surrounding
context.
Or whether you want it to do the move in every case, or in none of the
cases.

--

---
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/?hl=en.



--14dae9c09c1eb3003b04de69b9fe
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 June 2013 18:16, DeadMG <span dir="ltr">&lt;<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Er, if you return a lambda. I obviously don&#39;t mean for some arbitrary lambda creation.

<div class="HOEnZb"><div class="h5"><p></p>

<br><br></div></div></blockquote><div><br></div><div>&quot;Obviously&quot;. That&#39;s why I asked whether you really want [p] to mean move capture in<br>some situations, and copy-capture in others, depending on the surrounding context.<br>
</div><div>Or whether you want it to do the move in every case, or in none of the cases. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9c09c1eb3003b04de69b9fe--

.

------=_Part_173_27266360.1370446188222
Content-Type: text/plain; charset=ISO-8859-1


>
> That's why I asked whether you really want [p] to mean move capture
> in some situations, and copy-capture in others, depending on the
> surrounding context.


I thought this was pretty clear.

We already have an identical situation with function return values.


Amongst other things.

To be even more explicit about this, the only condition covered is of the
form return lambda;, much like existing implicit moves is only return
variable;. In addition, whilst the OP did not cover this, as far as I can
see, it would also have to include no uniform captures (although you could
employ some weasel wording for them if you really want which could be
viable) only reference and copy/move/this. Therefore,

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  return [p]{ return *p; };
}

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  auto x = [p]{ return *p; };
  return x;
}

std::function<int()> func()
{
  auto p = std::make_unique<int>();
  auto x = [p]{ return *p; };
  f(p);
  return x;
}

The latter two samples fail to compile because auto x = [p]{ return *p; };
is obviously not of the form return lambda so no implicit move can be
applied and unique_ptr has no copy constructor. So as I previously stated,
they behave exactly the same as if [p] { return *p; } was replaced with p
(also the return type adjusted and std::function requires copyability.. but
I get your meaning). The first sample compiles because return [p] { return
*p; } is of the form return lambda so an implicit move can be applied.
Again, this is exactly the same as if [p] { return *p; } was replaced with
p.

Now I'm pretty sure we should all be on the same page.

--

---
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/?hl=en.



------=_Part_173_27266360.1370446188222
Content-Type: text/html; charset=ISO-8859-1
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;">That's why I asked whether you really want [p]=
 to mean move capture in&nbsp;some situations, and copy-capture in others, =
depending on the surrounding context.</blockquote><div><br></div><div>I tho=
ught this was pretty clear.&nbsp;</div><div><br><div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
 1ex;">We already have an identical situation with function return values.&=
nbsp;</blockquote><div><br></div><div>Amongst other things.</div><div><br><=
/div><div>To be even more explicit about this, the only condition covered i=
s of the form return lambda;, much like existing implicit moves is only ret=
urn variable;. In addition, whilst the OP did not cover this, as far as I c=
an see, it would also have to include no uniform captures (although you cou=
ld employ some weasel wording for them if you really want which could be vi=
able) only reference and copy/move/this. Therefore,&nbsp;</div></div><div><=
br></div><div><div><div class=3D"GGVPNNKCHDB"><div class=3D"GGVPNNKCHDB">st=
d::function&lt;int()&gt; func()<br>{<br>&nbsp; auto p =3D std::make_unique&=
lt;int&gt;();<br></div><span style=3D"color: rgb(34, 34, 34);">&nbsp; retur=
n [p]{ return *p; };</span><br style=3D"color: rgb(34, 34, 34);"><div style=
=3D"color: rgb(34, 34, 34);">}</div><div style=3D"color: rgb(34, 34, 34);">=
<br></div>std::function&lt;int()&gt; func()<br>{<br>&nbsp; auto p =3D std::=
make_unique&lt;int&gt;();<br></div>&nbsp; auto x =3D [p]{ return *p; };<br>=
</div><div>&nbsp; return x;<br></div><div><div>}</div></div><div><div class=
=3D"GGVPNNKCHDB"><br>std::function&lt;int()&gt; func()<br>{<br>&nbsp; auto =
p =3D std::make_unique&lt;int&gt;();<br></div>&nbsp; auto x =3D [p]{ return=
 *p; };<br></div><div>&nbsp; f(p);<br></div><div><div>&nbsp; return x;<br><=
/div><div>}</div></div></div><div><br></div><div>The latter two samples fai=
l to compile because auto x =3D [p]{ return *p; }; is obviously not of the =
form return lambda so no implicit move can be applied and unique_ptr has no=
 copy constructor. So as I previously stated, they behave exactly the same =
as if [p] { return *p; } was replaced with p (also the return type adjusted=
 and std::function requires copyability.. but I get your meaning). The firs=
t sample compiles because return [p] { return *p; } is of the form return l=
ambda so an implicit move can be applied. Again, this is exactly the same a=
s if [p] { return *p; } was replaced with p.</div></div><div><br></div><div=
>Now I'm pretty sure we should all be on the same page.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_173_27266360.1370446188222--

.

------=_Part_573_31764735.1370446484105
Content-Type: text/plain; charset=ISO-8859-1


>
>  I think the bottom line is that
>
(1) lambdas are designed to capture the context; in this case when returned
from a function they should MOVE* *the captured local values* effortlessly*;
(2) some compilers already optimize that automatically (which means that
writing v1= std::move(v1) is just stating the obvious);
(3) [I said it before] the language already provides similar cases for
returning local variable values.



--

---
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/?hl=en.



------=_Part_573_31764735.1370446484105
Content-Type: text/html; charset=ISO-8859-1

<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV dir=ltr>
<DIV>I think the bottom line is that </DIV></DIV></BLOCKQUOTE>
<DIV>(1) lambdas are designed to capture the context; in this case when returned from a function they should&nbsp;MOVE<FONT color=#000000><STRONG> </STRONG>the captured local values<STRONG> effortlessly</STRONG>;</FONT></DIV>
<DIV><FONT color=#000000>(2) some compilers already optimize that automatically (which means that writing v1= std::move(v1) is just stating the obvious);</FONT></DIV>
<DIV><FONT color=#000000>(3) [I said it before] the language already provides similar cases for returning local variable values.</FONT></DIV>
<DIV><FONT color=#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000></FONT>&nbsp;</DIV>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_573_31764735.1370446484105--

.

--20cf306f750cd8986804de69facf
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 09:44, Jonathan Wakely <cxx@kayari.org> wrote:

>
> Why should lambdas be special?
> Can we please stop trying to squeeze every possible language feature into
> lambdas?
> Not everything can or should be done with lambdas, especially if it makes
> the rest of the language into second-class citizens.
>

+1.

If it is a general optimization, it should also work for a named struct
which does the same thing as a lambda.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



--20cf306f750cd8986804de69facf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 5 June 2013 09:44, Jonathan Wakely <span dir=3D"ltr">&lt;<a href=3D"mail=
to:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span> wrote:<b=
r><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>Why should lambdas be special?<br>Can we please stop trying to squ=
eeze every possible language feature into lambdas?<br>Not everything can or=
 should be done with lambdas, especially if it makes the rest of the langua=
ge into second-class citizens.<br>

</div></blockquote><div><br>+1.<br><br>If it is a general optimization, it =
should also work for a named struct which does the same thing as a lambda.<=
br clear=3D"all"></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;m=
ailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evi=
loverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf306f750cd8986804de69facf--

.

------=_Part_440_17111956.1370446943341
Content-Type: text/plain; charset=ISO-8859-1

It should do, but implementing it in the general case is solving Halting
Problem, so the real question is, "Where do we draw the line?". I, for one,
think that "Core language construct" is a fine place to draw lines. If you
can propose how it could be more general, that's great, but there's no
reason to sacrifice more generality just because full generality is
impossible.

--

---
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/?hl=en.



------=_Part_440_17111956.1370446943341
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It should do, but implementing it in the general case is solving Halting Pr=
oblem, so the real question is, "Where do we draw the line?". I, for one, t=
hink that "Core language construct" is a fine place to draw lines. If you c=
an propose how it could be more general, that's great, but there's no reaso=
n to sacrifice more generality just because full generality is impossible.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_440_17111956.1370446943341--

.

--14dae9c09c1ecc850104de6a185f
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 18:29, DeadMG <wolfeinstein@gmail.com> wrote:

>
> The latter two samples fail to compile because auto x = [p]{ return *p; };
> is obviously not of the form return lambda so no implicit move can be
> applied and unique_ptr has no copy constructor. So as I previously stated,
> they behave exactly the same as if [p] { return *p; } was replaced with p
> (also the return type adjusted and std::function requires copyability.. but
> I get your meaning). The
>

Except that if you do that replacement, they will compile fine. :P

As an initial reaction, I guess I would be less opposed to this than
Daniel. We could specify this in the same way
as moving-in-return, elision rules need to be applicable and there needs to
be no intervening referencing
of the variable that is captured this way (we might not need to constrain
it purely to returns). However, I
think Jonathan makes a very good point. And, given that you can move into a
lambda with the c++14
init-captures, I am not convinced this change is worth its cost.

--

---
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/?hl=en.



--14dae9c09c1ecc850104de6a185f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 18:29, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>The latter two samples fail to comp=
ile because auto x =3D [p]{ return *p; }; is obviously not of the form retu=
rn lambda so no implicit move can be applied and unique_ptr has no copy con=
structor. So as I previously stated, they behave exactly the same as if [p]=
 { return *p; } was replaced with p (also the return type adjusted and std:=
:function requires copyability.. but I get your meaning). The </div>
</blockquote><div><br></div><div>Except that if you do that replacement, th=
ey will compile fine. :P<br>=A0<br></div><div>As an initial reaction, I gue=
ss I would be less opposed to this than Daniel. We could specify this in th=
e same way<br>
as moving-in-return, elision rules need to be applicable and there needs to=
 be no intervening referencing<br>of the variable that is captured this way=
 (we might not need to constrain it purely to returns). However, I<br>think=
 Jonathan makes a very good point. And, given that you can move into a lamb=
da with the c++14<br>
</div><div>init-captures, I am not convinced this change is worth its cost.=
<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9c09c1ecc850104de6a185f--

.

------=_Part_1294_18224740.1370447623554
Content-Type: text/plain; charset=ISO-8859-1


>
> Except that if you do that replacement, they will compile fine. :P
>

Er, if you do

auto f() {
    auto p = std::make_unique<int>();
    auto x = p;

I'm pretty sure you will get a compiler error.

you can move into a lambda with the c++14 init-captures


You could also explicitly move a return value. That didn't stop us
implementing it before.

--

---
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/?hl=en.



------=_Part_1294_18224740.1370447623554
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div>Except that if you do that replacement, they will compil=
e fine. :P</div></div></div></blockquote><div><br></div><div>Er, if you do<=
/div><div><br></div><div>auto f() {</div><div>&nbsp; &nbsp; auto p =3D std:=
:make_unique&lt;int&gt;();</div><div>&nbsp; &nbsp; auto x =3D p;</div><div>=
<br></div><div>I'm pretty sure you will get a compiler error.&nbsp;<br></di=
v><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2=
04); border-left-style: solid; padding-left: 1ex;">you can move into a lamb=
da with the c++14 init-captures</blockquote><div><br></div><div>You could a=
lso explicitly move a return value. That didn't stop us implementing it bef=
ore.&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1294_18224740.1370447623554--

.

------=_Part_6626_17509820.1370447632899
Content-Type: text/plain; charset=ISO-8859-1

> And, given that you can move into a lambda with the c++14
> init-captures, I am not convinced this change is worth its cost.

It's worth the clarity, specially for lambdas!



>

--

---
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/?hl=en.



------=_Part_6626_17509820.1370447632899
Content-Type: text/html; charset=ISO-8859-1

<FONT color=#9900ff>&gt; And, given that you can move into a lambda with the c++14<BR></FONT>
<DIV><FONT color=#9900ff>&gt; init-captures, I am not convinced this change is worth its cost.</FONT></DIV>
<DIV><FONT color=#9900ff></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000>It's worth the clarity, specially for lambdas!</FONT></DIV>
<DIV><FONT color=#9900ff>&nbsp;</DIV>
<DIV><BR></DIV></FONT>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV dir=ltr>
<DIV>&nbsp;</DIV></DIV></BLOCKQUOTE>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6626_17509820.1370447632899--

.

--047d7b6da08459c0d304de6a524a
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 18:53, DeadMG <wolfeinstein@gmail.com> wrote:

> Except that if you do that replacement, they will compile fine. :P
>>
>
> Er, if you do
>
> auto f() {
>     auto p = std::make_unique<int>();
>     auto x = p;
>
> I'm pretty sure you will get a compiler error.
>

Ah, I stand corrected. With auto&&, the situation is different.


> you can move into a lambda with the c++14 init-captures
>
>
> You could also explicitly move a return value. That didn't stop us
> implementing it before.
>
>
>
Fair enough. I still don't think it's a superior solution to an
init-capture. It would be nice-to-have
since it would optimize cases where people don't explicitly move, so
there's some benefit in the idea.

--

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



--047d7b6da08459c0d304de6a524a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 18:53, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Except that if you do that=
 replacement, they will compile fine. :P</div></div></div></blockquote><div=
><br></div></div><div>Er, if you do</div><div><br></div><div>auto f() {</di=
v>
<div class=3D"im"><div>=A0 =A0 auto p =3D std::make_unique&lt;int&gt;();</d=
iv></div><div>=A0 =A0 auto x =3D p;</div><div><br></div><div>I&#39;m pretty=
 sure you will get a compiler error.=A0<br></div></blockquote><div><br></di=
v><div>Ah, I stand corrected. With auto&amp;&amp;, the situation is differe=
nt.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div></div><div><br></div><div><di=
v class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
you can move into a lambda with the c++14 init-captures</blockquote><div><b=
r></div></div><div>You could also explicitly move a return value. That didn=
&#39;t stop us implementing it before.=A0</div></div><div class=3D"HOEnZb">
<div class=3D"h5">

<p></p>

<br></div></div></blockquote><div><br></div><div>Fair enough. I still don&#=
39;t think it&#39;s a superior solution to an init-capture. It would be nic=
e-to-have<br>since it would optimize cases where people don&#39;t explicitl=
y move, so there&#39;s some benefit in the idea. <br>
</div><div><br></div><div><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6da08459c0d304de6a524a--

.

------=_Part_3_29845427.1370450174846
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. j=FAnius 5., szerda 18:02:16 UTC+2 id=F5pontban Ville Voutilainen a=
=20
k=F6vetkez=F5t =EDrta:
>
>
>
>
> On 5 June 2013 18:53, DeadMG <wolfei...@gmail.com <javascript:>> wrote:
>
>> Except that if you do that replacement, they will compile fine. :P
>>>
>>
>> Er, if you do
>>
>> auto f() {
>>     auto p =3D std::make_unique<int>();
>>     auto x =3D p;
>>
>> I'm pretty sure you will get a compiler error.=20
>>
>
> Ah, I stand corrected. With auto&&, the situation is different.
>
> =20
Well you can compile that, but it won't be a unique_ptr<int>&&, just a=20
unique_ptr<int>&, as "p" in the second line is not an rvalue...

Regards, Robert

--=20

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



------=_Part_3_29845427.1370450174846
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. j=FAnius 5., szerda 18:02:16 UTC+2 id=F5pontban Ville Voutila=
inen a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 5 June 2013 =
18:53, DeadMG <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"cowLZbcH6hMJ">wolfei...@gmail.com</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Except that if you do that=
 replacement, they will compile fine. :P</div></div></div></blockquote><div=
><br></div></div><div>Er, if you do</div><div><br></div><div>auto f() {</di=
v>
<div><div>&nbsp; &nbsp; auto p =3D std::make_unique&lt;int&gt;();</div></di=
v><div>&nbsp; &nbsp; auto x =3D p;</div><div><br></div><div>I'm pretty sure=
 you will get a compiler error.&nbsp;<br></div></blockquote><div><br></div>=
<div>Ah, I stand corrected. With auto&amp;&amp;, the situation is different=
..<br></div></div><br></div></div></blockquote><div>&nbsp;<br>Well you can c=
ompile that, but it won't be a unique_ptr&lt;int&gt;&amp;&amp;, just a uniq=
ue_ptr&lt;int&gt;&amp;, as "p" in the second line is not an rvalue...<br><b=
r>Regards, Robert<br><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3_29845427.1370450174846--

.

------=_Part_4327_19172549.1370450959803
Content-Type: text/plain; charset=ISO-8859-1

This should not be lambda-specific, could be applied to all automatic
variable:

std::vector<int> make_foo_vect();
void use_vect(std::vector<int> asd);
void f() {
  std::vector<int> foo = make_foo_vect();
  use_vect(foo); //copy
  use_vect(foo); //copy
  use_vect(foo); //move
}
A compiler can detect when is the last usage, where it can handle it as an
rvalue. Even if it is not 'base' standard, can be made as an allowed
optimization, just like copy elision.

I for now don't see any code this could break, have think about it a bit.

Regards, Robert

--

---
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/?hl=en.



------=_Part_4327_19172549.1370450959803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This should not be lambda-specific, could be applied to all automatic varia=
ble:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> make_foo_vect</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> use_vect</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">vector</span><span style=3D"color: #080;" class=3D"styled-=
by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> asd</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">vector</span><span style=3D"color: #080;" class=3D=
"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> make_foo_vect</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; use_vect</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//copy</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; use_vect=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//copy</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp; use_vect</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//move</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></di=
v></code></div>A compiler can detect when is the last usage, where it can h=
andle it as an rvalue. Even if it is not 'base' standard, can be made as an=
 allowed optimization, just like copy elision.<br><br>I for now don't see a=
ny code this could break, have think about it a bit.<br><br>Regards, Robert=
<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4327_19172549.1370450959803--

.

--001a11c3c42658a7d204de6b5279
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 5 June 2013 19:36, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:

>
>
> 2013. j=FAnius 5., szerda 18:02:16 UTC+2 id=F5pontban Ville Voutilainen a
> k=F6vetkez=F5t =EDrta:
>
>>
>>
>>
>> On 5 June 2013 18:53, DeadMG <wolfei...@gmail.com> wrote:
>>
>>> Except that if you do that replacement, they will compile fine. :P
>>>>
>>>
>>> Er, if you do
>>>
>>> auto f() {
>>>     auto p =3D std::make_unique<int>();
>>>     auto x =3D p;
>>>
>>> I'm pretty sure you will get a compiler error.
>>>
>>
>> Ah, I stand corrected. With auto&&, the situation is different.
>>
>>
> Well you can compile that, but it won't be a unique_ptr<int>&&, just a
> unique_ptr<int>&, as "p" in the second line is not an rvalue...
>
>
Yep, and returning _that_ unique_ptr& will not move, so it will still fail
to compile.

--=20

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



--001a11c3c42658a7d204de6b5279
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 June 2013 19:36, R=F3bert D=E1vid <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>2013. j=FAnius 5., szerda 18:02:16 U=
TC+2 id=F5pontban Ville Voutilainen a k=F6vetkez=F5t =EDrta:<div class=3D"i=
m"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 5 June 2013=
 18:53, DeadMG <span dir=3D"ltr">&lt;<a>wolfei...@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Except that if you do that=
 replacement, they will compile fine. :P</div></div></div></blockquote><div=
><br></div></div><div>Er, if you do</div><div><br></div><div>auto f() {</di=
v>

<div><div>=A0 =A0 auto p =3D std::make_unique&lt;int&gt;();</div></div><div=
>=A0 =A0 auto x =3D p;</div><div><br></div><div>I&#39;m pretty sure you wil=
l get a compiler error.=A0<br></div></blockquote><div><br></div><div>Ah, I =
stand corrected. With auto&amp;&amp;, the situation is different.<br>
</div></div><br></div></div></blockquote></div><div>=A0<br>Well you can com=
pile that, but it won&#39;t be a unique_ptr&lt;int&gt;&amp;&amp;, just a un=
ique_ptr&lt;int&gt;&amp;, as &quot;p&quot; in the second line is not an rva=
lue...<br>
<br></div></blockquote><div><br></div><div>Yep, and returning _that_ unique=
_ptr&amp; will not move, so it will still fail to compile. <br></div></div>=
<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3c42658a7d204de6b5279--

.

------=_Part_24_12188580.1370455778274
Content-Type: text/plain; charset=ISO-8859-1

@Robert: Try what happens when use_vect uses a hidden global reference to
it's arguments, directly or indirectly.

The simple fact is that generalized moving is not possible. It is only
possible in some very limited contexts. Lambdas are one of those contexts.
Finding others will be non-trivial.

--

---
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/?hl=en.



------=_Part_24_12188580.1370455778274
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

@Robert: Try what happens when use_vect uses a hidden global reference to i=
t's arguments, directly or indirectly.<div><br></div><div>The simple fact i=
s that generalized moving is not possible. It is only possible in some very=
 limited contexts. Lambdas are one of those contexts. Finding others will b=
e non-trivial.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_24_12188580.1370455778274--

.

------=_Part_388_10145948.1370621635724
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 5, 2013 5:34:44 PM UTC+2, Mikhail Semenov wrote:
>
>  I think the bottom line is that
>>
> (1) lambdas are designed to capture the context; in this case when
> returned from a function they should MOVE* *the captured local values*effortlessly
> *;
> (2) some compilers already optimize that automatically (which means that
> writing v1= std::move(v1) is just stating the obvious);
>
>
Really? Those compilers are overreaching. Copy elision is a special license
granted by the standard to optimize as if "copy construct something and
destroy the source" has no side effects, even if copy constructor and/or
destructor actually do. Move-for-NRVO is yet another special license to
optimize as if local variables referenced in a return statement cannot be
referenced after the return value is constructed, even though destructors
of other local variables can.

Basically, both optimizations can cause observable behavior to change,
which is precisely why they are the only optimizations mentioned in the
standard - every other optimization is covered by the as-if rule, but these
aren't, so they need to be allowed specifically.

Extending move-for-NRVO to any other situation must be a change in the
standard; a compiler cannot do it on its own and stay within the standard.

--

---
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/?hl=en.



------=_Part_388_10145948.1370621635724
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 5, 2013 5:34:44 PM UTC+2, Mikhail Semenov wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><blockquote style=3D"BORDER-LE=
FT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class=3D"gmail=
_quote">
<div dir=3D"ltr">
<div>I think the bottom line is that </div></div></blockquote>
<div>(1) lambdas are designed to capture the context; in this case when ret=
urned from a function they should&nbsp;MOVE<font color=3D"#000000"><strong>=
 </strong>the captured local values<strong> effortlessly</strong>;</font></=
div>
<div><font color=3D"#000000">(2) some compilers already optimize that autom=
atically (which means that writing v1=3D std::move(v1) is just stating the =
obvious);</font></div>
<div><br></div></blockquote><div><br></div><div>Really? Those compilers are=
 overreaching. Copy elision is a special license granted by the standard to=
 optimize as if "copy construct something and destroy the source" has no si=
de effects, even if copy constructor and/or destructor actually do. Move-fo=
r-NRVO is yet another special license to optimize as if local variables ref=
erenced in a return statement cannot be referenced after the return value i=
s constructed, even though destructors of other local variables can.</div><=
div><br></div><div>Basically, both optimizations can cause observable behav=
ior to change, which is precisely why they are the only optimizations menti=
oned in the standard - every other optimization is covered by the as-if rul=
e, but these aren't, so they need to be allowed specifically.</div><div><br=
></div><div>Extending move-for-NRVO to any other situation must be a change=
 in the standard; a compiler cannot do it on its own and stay within the st=
andard.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_388_10145948.1370621635724--

.