220 36349 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Treating local variables as rvalues in return statements Date: Mon, 25 Dec 2017 19:17:11 -0800 (PST) Lines: 388 Approved: news@gmane.org Message-ID: References: <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_17373_1149245851.1514258232100" X-Trace: blaine.gmane.org 1514258116 16999 195.159.176.226 (26 Dec 2017 03:15:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 03:15:16 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOP6Q3JAKGQEAHQLDCQ@isocpp.org Tue Dec 26 04:15:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTfhv-00044Y-O5 for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 04:15:12 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id u143sf14714494vkb.0 for ; Mon, 25 Dec 2017 19:17:14 -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:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=wtUnsS4mD+8kmEQBWyzWUhXuc09hB0LWJzf2GLKjwQ4=; b=QfcFN0nOxLRbtePKItfrJsksjokP7mVYk9JCCM2CZXCwKPoEOqgzv64uQ0wFYAAy0F wELpsGk9LABg2fedQTWt/fbcwOXLVyF1ZWEGmp+5QE+c0vY1l6UKB5r0+UHILIi1tEdT 6ZXAPNzCbVwIOmgzNGHvT666MvR+oLqgL3TQvwee3PXCJrfGtjH4adD/WMSufILQkBHt rcAwY0gPqQBSuBKmCMqmc/db9zr/uexhbWS/VV1f6hl1oJk1nwOMBzR6QaJ1p2AcgmN7 TuxuNlKqyxTe7DpeiWfPQFcmgr7RNNxH/WyqoQN5j+Yxbwb9UEq6/arvOSO60f06UyjI vsMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=wtUnsS4mD+8kmEQBWyzWUhXuc09hB0LWJzf2GLKjwQ4=; b=aN7lzMvc/yFViaawW9ojHk68Q15cy2+9lEqbf3EDLzI9nSPjphRDEwg4UKLa/4UsrG 5uD2378VMlPcTmiBdqGXFQA6R9n0gcaLTzzzCbb5Oj0gEOW/BtfvJ9oHGrbj/YcGM9ho l9GEe+AYSsVzA6TJJkgB2Z1me6KRplFgP8/qcu8i1OS4dc8n6ACkMmm6KblIxedwRSmF K2xwMETx/i22iiIfhOVQZIe3R1lGGbW6rK1TuKIPwUZDJgHsXmp9sgIzVRbfva+zLNOr pRwlOoS42LLh42VK/N+QlJifqPJ/0wO0aaFwhOpItQ2jfNCoy0YCVrR5wWbwin5dd0/l sVsg== 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:in-reply-to:references :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=wtUnsS4mD+8kmEQBWyzWUhXuc09hB0LWJzf2GLKjwQ4=; b=rm+pi//dGq2B1I0E3sD9R7rLhTeRjKDerJM4+4j5rSfUhrpancF2IGxliTE0pc6mtl VsGhetV2vK63yVJUYUpQQbSRxl00Vi7ykS7/SYNsSuja0S9yG3cwCatzK99AVKQah/4v 4JK6a9AHNl/pfpf1br5ZUEkamQ7KF2v8xLoHXgncyviIp5WpyJl4vlWTw0xxC/eE4Y2h q+WkjvLNb+yp3xNd6UTfGmTE0gwO6dRPLZVOh4B3D73LKVXM+LoIVYA+brYTm3iaDQyX DiNv4xY7bX7OtCpkzEtIpTiKheorUDw3ihBYjXtR5Zqs1+ksWxLw5naFKg2yX+/D4w52 qFFg== X-Gm-Message-State: AKGB3mI55rDp7B0PUHUN7pNFdATN/WmlLmYm15J9QIhTZXZ8n90O8909 hdmWWLOM1r6PaKW19hpyU2v9IQ== X-Google-Smtp-Source: ACJfBos3PskKlh39pyP7yG4gKx7ZPThy+OBa25kKImFdbR/NzWZ6xe8u4xSRKQQf5+1l4m0Z+4TPWA== X-Received: by 10.31.191.1 with SMTP id p1mr11044701vkf.73.1514258234224; Mon, 25 Dec 2017 19:17:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.43.69 with SMTP id q5ls2834435uaj.17.gmail; Mon, 25 Dec 2017 19:17:12 -0800 (PST) X-Received: by 10.31.61.149 with SMTP id k143mr2233449vka.7.1514258232636; Mon, 25 Dec 2017 19:17:12 -0800 (PST) In-Reply-To: <4ff5fe2d-0945-491f-9888-479b8e866ace@isocpp.org> X-Original-Sender: jmckesson@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:36349 Archived-At: ------=_Part_17373_1149245851.1514258232100 Content-Type: multipart/alternative; boundary="----=_Part_17374_1602619044.1514258232100" ------=_Part_17374_1602619044.1514258232100 Content-Type: text/plain; charset="UTF-8" On Monday, December 25, 2017 at 9:10:02 PM UTC-5, jgot...@gmail.com wrote: > > 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. > The sooner people learn to use `std::move` when they want to move things, the better. "Intuitive" or not, it's better off in the long run to make moving explicit. 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. > It would also result in breaking lots of stuff. The reason why `return variablename;` can be treated as an rvalue is because it is a simple expression: one which does nothing more than name an automatic object. Once you allow this to involve anything more complicated than that, it now becomes possible to implicitly move from an lvalue and still access the moved-from object later. That's bad. Consider the following: std::string str = ...; auto str2 = str + compute(str); return str2; That code should be equivalent to: std::string str = ...; return str + compute(str); But with your proposal, it isn't. If `compute(str)` has an rvalue overload or an overload that takes a `string` by value, then these two pieces of code will have fundamentally different behavior. Specifically, it will have* undefined* behavior, since `str` will have been moved from by the time `operator+` gets called on it. Stopping things like this is* precisely why* `std::move` exists. If you have an lvalue, you are explicitly required to use `std::move` on it if you want to move it. Otherwise, it gets copied. `return variablename;` (and `throw variablename`) is the only case of implicit moving from an lvalue. And this case is the only one because it is guaranteed by the language that you cannot do anything with `variablename` after the move takes place. If you allow an arbitrary expression, that guarantee goes away. And lets' not forget: the meaning of `return str + compute(str);` is already* well defined* in C++ right now. If you change its meaning, you are breaking people's existing code. Code that worked fine in C++98. -- 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/d5b5434c-6300-4f82-92b4-a439696d6020%40isocpp.org. ------=_Part_17374_1602619044.1514258232100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, December 25, 2017 at 9:10:02 PM UTC-5, jgot...@= gmail.com wrote:
Since C++11, if a function returns a local variable it will move from fr= om that variable.

std::string foo(){
=C2=A0std::string ou= tput{&q= uot;Hello world"};
=C2=A0return output; // output is treated as an rvalue and moved from.
}

However, if foo's return statement were something l= ike=C2=A0=C2=A0
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.=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=A0pr= oposes adding an rvalue overload to std::ostringstream's str() method t= hat 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= &m= yType) = {
= =C2=A0 =C2=A0std::ostringstream os;
=C2=A0 =C2=A0 //= output the fields of myType to os.
= =C2=A0 =C2=A0return os.str();
}
<= /div>
Even if P0408r3 were accepted, this function would call the lvalue= overload of ostringstream::str().=C2=A0 In order to get the rvalue overloa= d, the user would have to return std::move(os).str(), which is not very int= uitive.

The sooner people learn= to use `std::move` when they want to move things, the better. "Intuit= ive" or not, it's better off in the long run to make moving explic= it.

I think that naturally treating os as an rvalue in this cas= e could result in faster code without programmers having to worry about whe= re to put a move statement.

It = would also result in breaking lots of stuff.

The r= eason why `return variablename;` can be treated as an rvalue is because it = is a simple expression: one which does nothing more than name an automatic = object. Once you allow this to involve anything more complicated than that,= it now becomes possible to implicitly move from an lvalue and still access= the moved-from object later.

That's bad. Cons= ider the following:

std::string str =3D ...;
auto str2 =3D s= tr + compute<= span class=3D"styled-by-prettify" style=3D"color: #660;">(str);
return str2;

That code = should be equivalent to:

std::string str =3D ...;
return str + compute(st= r);=

But with your proposal, it isn't. If `compute(str)` = has an rvalue overload or an overload that takes a `string` by value, then = these two pieces of code will have fundamentally different behavior. Specif= ically, it will have undefined behavior, since `str` will have been = moved from by the time `operator+` gets called on it.

Stopping things= like this is precisely why `std::move` exists. If you have an lvalu= e, you are explicitly required to use `std::move` on it if you want to move= it. Otherwise, it gets copied.

`return variablename;` (and `throw var= iablename`) is the only case of implicit moving from an lvalue. And this ca= se is the only one because it is guaranteed by the language that you cannot= do anything with `variablename` after the move takes place.

If you al= low an arbitrary expression, that guarantee goes away.

And lets' n= ot forget: the meaning of `return str + compute(str);` is already well d= efined in C++ right now. If you change its meaning, you are breaking pe= ople's existing code. Code that worked fine in C++98.

--
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/d5b5434c-6300-4f82-92b4-a439696d6020= %40isocpp.org.
------=_Part_17374_1602619044.1514258232100-- ------=_Part_17373_1149245851.1514258232100-- .