220 36348 <4ff5fe2d-0945-491f-9888-479b8e866ace@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: jgottman6@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Treating local variables as rvalues in return statements Date: Mon, 25 Dec 2017 18:10:02 -0800 (PST) Lines: 152 Approved: news@gmane.org Message-ID: <4ff5fe2d-0945-491f-9888-479b8e866ace@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16888_358189822.1514254202693" X-Trace: blaine.gmane.org 1514254092 22039 195.159.176.226 (26 Dec 2017 02:08:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 02:08:12 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD7LHGWIQEPRB666Q3JAKGQED72OHAA@isocpp.org Tue Dec 26 03:08:08 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTeew-00055T-IQ for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 03:08:02 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id x135sf932971vke.10 for ; Mon, 25 Dec 2017 18:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=nIE2bCZfBkJRZ1Jd6urFk19xxGlT6R+1DIR79PjnELE=; b=z4+bZr5XWnloLVg5bvqiP2/gU+wgicDlpkWzJckyLqtk2nwz/GxaZVfzQ5zEhDE7/L PXOCKAoOhqanIkt3ys/I0helirjELkBv3gvmPVif2WJCn1g5FeaMo+wumHwoSxG9hefY tL6lRariLJwKdUeyoUgWgigdIwY8RY4YXLxk+oHqH9WkAXwzFfFKx+TKke8TuItbqGoG ygP9D7LD22KjAsWlPnWfW+7veIoLQuHrcCrPcMxDLfsUbebzsGUBUpcKFj18mG3WwheD 0qH4SLqSMXyEhy3dL7cs40gqJLcBd6lNpQPZllYkoX4jLiGCvzhkjGBAS2nANCNYbU4b 7bKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=nIE2bCZfBkJRZ1Jd6urFk19xxGlT6R+1DIR79PjnELE=; b=kTRBVNzN3cL9SkNMQwuGFPPFFOMCOhPWOon0NgF6mf1+AJB6Mg5XtOUXOhqZMYRPzL crUCRyTqAtkgK9IPAE/01fye8VBatz447KsT04ZpcaVnvfHZvljeiN3rcMY58H3b5qTy S9PIeCoMC5+YxZsnjbg+s6xDkISvo7hz9v7uvwAO3B3ufnxbWtMFkeyAQsMMoJTl2CZg si0IHDmPsjzoURmUMS+RZCKBPAWqIIHCPUpXFIetAnF5c4ye/PzJ00XHz0ivfaxTnuoa WaWKtlEJq+oysU+UwPLEhkBWcLmst7LWXqdo8+XfPJfK/k+4BHRW00x5wPJU0K97fAex V8wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=nIE2bCZfBkJRZ1Jd6urFk19xxGlT6R+1DIR79PjnELE=; b=iuJtLXp5mZ6Q5Cieos1XnuKezWhDj0sGRQkY64MUhtDn4r2SoozjJYMpS9Hp2f3pUH 5nhX2eOlJn5RBeHcShaDwOSu2JQxdpDrHbJg7+wCpjr7kNKiBad+W2mZ0KZ3WLQd/vLq hpa2E2B8Dm2OA7YkKgmmZMPdFAbtw+9ToYo5PwosIF8Lmx62if014b10xpKWWcqZGcMs ohq0Ct9lNfmeODsYwA1JcKKloSZ/Fa8gbcdjnOr8mzmczq5mGdbsEQmAP5ELmdnCujSS aPwp/2LhxmvFM2jF4mHkLCysB1zf8J164AzMf6QfbTpAehiuFr+ecUfpOT+0I2zIaYjD oceA== X-Gm-Message-State: AKGB3mLVnu7NaFrxMIkRv/SEsy7vE6hZ+gCmR5cxB96mhq+j5kgPd/Xq NMkyEzwVVvLKLkxhx0vuwA41wA== X-Google-Smtp-Source: ACJfBosSFwBokYro6Kkin5oqvdmYQbpMP5SpwqdLZUCeXvcIy5fpp9sHOhFcqKdcd4naEqxB+ZBN1A== X-Received: by 10.176.112.57 with SMTP id u25mr12827047ual.85.1514254204990; Mon, 25 Dec 2017 18:10:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.54.140 with SMTP id d134ls2614355vka.15.gmail; Mon, 25 Dec 2017 18:10:03 -0800 (PST) X-Received: by 10.31.158.84 with SMTP id h81mr2224743vke.6.1514254203230; Mon, 25 Dec 2017 18:10:03 -0800 (PST) X-Original-Sender: jgottman6@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:36348 Archived-At: ------=_Part_16888_358189822.1514254202693 Content-Type: multipart/alternative; boundary="----=_Part_16889_293035515.1514254202693" ------=_Part_16889_293035515.1514254202693 Content-Type: text/plain; charset="UTF-8" Since C++11, if a function returns a local variable it will move from from that variable. std::string foo(){ std::string output{"Hello world"}; return output; // output is treated as an rvalue and moved from. } However, if foo's return statement were something like return my_function(output); then output would be treated as an lvalue, even though it is a local variable that is about to go out of scope. I think it could be a major improvement if the local variable could be treated as an rvalue in this case as well. For example, P0408r3 proposes adding an rvalue overload to std::ostringstream's str() method that moves instead of copies from the ostringstream's internal buffer. Most functions that use ostringstreams look like the following: std::string to_string(const MyType &myType) { std::ostringstream os; // output the fields of myType to os. return os.str(); } Even if P0408r3 were accepted, this function would call the lvalue overload of ostringstream::str(). In order to get the rvalue overload, the user would have to return std::move(os).str(), which is not very intuitive. I think that naturally treating os as an rvalue in this case could result in faster code without programmers having to worry about where to put a move statement. Joe Gottman -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ff5fe2d-0945-491f-9888-479b8e866ace%40isocpp.org. ------=_Part_16889_293035515.1514254202693 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since C++11, if a function returns a local variable it wil= l move from from that variable.

std::string foo(){
=C2=A0std::string o= utput{"Hello wo= rld"}= ;
=C2=A0return output; = // output = is treated as an rvalue and moved from.
}

However, if f= oo's return statement were something like=C2=A0=C2=A0
retu= rn my_func= tion(output);
then output would be treated as an lvalue, even though it i= s a local variable that is about to go out of scope.=C2=A0 I think it could= be a major improvement if the local variable could be treated as an rvalue= in this case as well.=C2=A0 For example,=C2=A0P0408r3=C2=A0propos= es adding an rvalue overload to std::ostringstream's str() method that = moves instead of copies from the ostringstream's internal buffer.=C2=A0= Most functions that use ostringstreams look like the following:
=
std::string to_string(const MyType= &myType) {
=C2=A0 =C2=A0std::ostringstream os;
=C2=A0 =C2=A0 // output the fields of myType to os.
=C2=A0 =C2=A0= return os.str();
}


Even= if P0408r3 were accepted, this function would call the lvalue overload of = ostringstream::str().=C2=A0 In order to get the rvalue overload, the user w= ould have to return std::move(os).str(), which is not very intuitive.=C2=A0= I think that naturally treating os as an rvalue in this case could result = in faster code without programmers having to worry about where to put a mov= e statement.

Joe Gottman

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/4ff5fe2d-0945-491f-9888-479b8e866ace= %40isocpp.org.
------=_Part_16889_293035515.1514254202693-- ------=_Part_16888_358189822.1514254202693-- .