220 8254 article Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Generalized lambda capture: returning values not captured by reference, should not they be moved? Date: Fri, 27 Dec 2013 14:26:00 -0500 Lines: 190 Approved: news@gmane.org Message-ID: References: <9a553579-08d1-4d60-a288-b1cb95056127@isocpp.org> <02f29ec5-63e7-4ac9-9cef-1e4c374b3614@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11333c2276ae3e04ee8910c8 X-Trace: ger.gmane.org 1388172356 14010 80.91.229.3 (27 Dec 2013 19:25:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Dec 2013 19:25:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIIVO6GQULBBSNI66KQKGQEM6CT64I@isocpp.org Fri Dec 27 20:26:03 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vwd2p-0004ri-8n for gclcip-std-proposals@m.gmane.org; Fri, 27 Dec 2013 20:26:03 +0100 Original-Received: by mail-ob0-f197.google.com with SMTP id vb8sf42878192obc.0 for ; Fri, 27 Dec 2013 11:26:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=ynJBJeAnDZF3wWcm5Gh/u72pIKb6ZWpacRQ5517RVYU=; b=QIb42g+0Gti+2ZqoAMZufHgWFLfuvD9yPq80+y08fLf9SO417X7PvSvno0UQBFAB3k S/taKP2P9HkFyhn9adE4T9kI0qhAM+ojytr2fIL5HEqoOs/IkYP3E3iheh/Qmt7AhRZX NwgQ6l5s5a40Le+O+DaaG97XV2fZ2kWcnxqW5gvxlNgq2i12G4mLPIgpe00rsqUVnfHr Dfut0O/55OYcV+bodns5p70bwwGbD1rk1bd8EgL0Vylup631GVm+ZYXY8vU53N5wcxY3 lGc9mpx71NeZc0yED2j2iZqFFK3nZtsV9qX5/XeX7Bv4v3joBnHC1jkXNrcj1t6VyQ2/ 1QGw== X-Gm-Message-State: ALoCoQmXVWZ3YAqRYbq0jsduJEWHqPO+Ce7H4ePMa3cN7vhjJ+FWQjr5pcgf7jTHtRdPDOHWGQ3o X-Received: by 10.43.102.136 with SMTP id de8mr17649920icc.20.1388172362022; Fri, 27 Dec 2013 11:26:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.121.98 with SMTP id lj2ls3022057qeb.45.gmail; Fri, 27 Dec 2013 11:26:01 -0800 (PST) X-Received: by 10.236.171.195 with SMTP id r43mr34700173yhl.56.1388172361338; Fri, 27 Dec 2013 11:26:01 -0800 (PST) Original-Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [2607:f8b0:400c:c01::22e]) by mx.google.com with ESMTPS id x18si29534027qef.13.2013.12.27.11.26.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Dec 2013 11:26:01 -0800 (PST) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400c:c01::22e as permitted sender) client-ip=2607:f8b0:400c:c01::22e; Original-Received: by mail-ve0-f174.google.com with SMTP id pa12so4948129veb.19 for ; Fri, 27 Dec 2013 11:26:01 -0800 (PST) X-Received: by 10.221.18.70 with SMTP id qf6mr7861984vcb.37.1388172360984; Fri, 27 Dec 2013 11:26:00 -0800 (PST) Original-Sender: dribeas@gmail.com Original-Received: by 10.52.178.101 with HTTP; Fri, 27 Dec 2013 11:26:00 -0800 (PST) In-Reply-To: <02f29ec5-63e7-4ac9-9cef-1e4c374b3614@isocpp.org> X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400c:c01::22e as permitted sender) smtp.mail=dribeas@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8254 Archived-At: --001a11333c2276ae3e04ee8910c8 Content-Type: text/plain; charset=ISO-8859-1 Agree that you don't want to implicitly move. Consider the non-lambda equivalent version: struct X { std::string msg; X(const std::string& msg) : msg(msg) {} std::string message() const { return msg; } }; Would you move 'msg' in the 'message()' function call? Surely not. Lambdas are not that different from that piece of code, among other things by default the generated 'operator()' is 'const'. In your example you removed that 'const' by making the lambda mutable, but this would also create another source of confusion: For 'mutable' lambdas it would move but for non-mutable ones it would copy (there is no constructor taking 'std::string const &&'). I don't see that this should be the default. For those use cases where it might make sense (a lambda that is known to be evaluated only once...) you can always type 'std::move' in your code. David On Fri, Dec 27, 2013 at 1:45 PM, Cassio Neri wrote: > > > On Friday, December 27, 2013 3:58:33 PM UTC-2, Mikhail Semenov wrote: > >> I have looked at the following code (A is the type of x and y): >> >> auto f1 = [x = std::move(x),&y]() mutable ->A >> { >> // some processing >> *return std::move(x);* // should not the value be moved by >> default here? >> }; >> > > No, as Ville has explained. > > In addition, I disagree that an implicit move would be a good idea in this > case because users can call f1 more than once and expect, at each time, > to get the same result: > > auto x1 = f1(); > auto x2 = f1(); > > If f1.x is implicitly moved, then (likely) x1 != x2. (Of course, the user > could do: > > auto x1 = f1(); > auto x2 = x1; > > but still!) > > Giving away onwership of an object that can still be used (like f1 and > f1.x) > should be made explicitly by the programmer instead of implicitly by the > compiler. > > A special rule in this sense could be useful if the lambda itself was an > xvalue but additional constraints must hold. For instance the lambda should > not be returned otherwise, we're back to square one: > > auto foo() { > A x, y ; // as before > auto f1 = ... // as before > return f1; > } > > auto f2 = foo(); > auto x1 = f2(); > auto x2 = f2(); > > -- > > --- > 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/. > -- --- 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/. --001a11333c2276ae3e04ee8910c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree that you don't want to implicitly move. Consider= the non-lambda equivalent version:

struct X {
=A0 =A0std::string= msg;
=A0 =A0X(const std::string& msg) : msg(msg) {}
=A0 =A0std::= string message() const {
=A0 =A0 =A0 =A0return msg;
=A0 =A0}
};

Would you move 'msg= ' in the 'message()' function call? Surely not. Lambdas are not= that different from that piece of code, among other things by default the = generated 'operator()' is 'const'. In your example you remo= ved that 'const' by making the lambda mutable, but this would also = create another source of confusion:

For 'mutable' lambdas it would move but for non-mutable ones it= would copy (there is no constructor taking 'std::string const &&am= p;'). I don't see that this should be the default. For those use ca= ses where it might make sense (a lambda that is known to be evaluated only = once...) you can always type 'std::move' in your code.

=A0 =A0David


On Fri, Dec 27, 2013 at 1:45 PM, Cassio Neri <= ;cassio.neri@gma= il.com> wrote:


O= n Friday, December 27, 2013 3:58:33 PM UTC-2, Mikhail Semenov wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
I have looked at the following code= (A is the type of x and y):
=A0
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a= uto f1 =3D [x =3D std::move(x),&y]() mutable ->A
=A0=A0=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 // some pro= cessing=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 = return std::move(x);=A0=A0// should not = the value be moved by default=A0here?
=A0=A0=A0=A0=A0=A0=A0=A0 };
=
No, as Ville has explained.

In addition, I disagree that an impl= icit move would be a good idea in this
case because users can call f1 mo= re than once and expect, at each time,
to get the same result:

auto x1 =3D f1();
auto x2 =3D f1();
If f1.x is implicitly moved, then (likely) x1 !=3D x2. (Of course, the us= er
could do:

auto x1 =3D f1();
auto x2 =3D x1;

but stil= l!)

Giving away onwership of an object that can still be used (like f1 and = f1.x)
should be made explicitly by the programmer instead of implicitly = by the
compiler.

A special rule in this sense could be useful if = the lambda itself was an
xvalue but additional constraints must hold. For instance the lambda should=
not be returned otherwise, we're back to square one:

auto fo= o() {
=A0 A x, y ; // as before
=A0 auto f1 =3D ... // as before
= =A0 return f1;
}

auto f2 =3D foo();
auto x1 =3D f2();
auto x2 =3D f2();

--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;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/gro= up/std-proposals/.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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-proposals/<= /a>.
--001a11333c2276ae3e04ee8910c8-- .