220 20963 <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto return Date: Mon, 28 Sep 2015 22:27:13 -0700 (PDT) Lines: 200 Approved: news@gmane.org Message-ID: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5309_362540967.1443504433630" X-Trace: ger.gmane.org 1443504440 1636 80.91.229.3 (29 Sep 2015 05:27:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 05:27:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMWCVCYAKGQEIZG4BNA@isocpp.org Tue Sep 29 07:27:19 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZgnRd-0000Ky-C0 for gclcip-std-proposals@m.gmane.org; Tue, 29 Sep 2015 07:27:17 +0200 Original-Received: by oixx17 with SMTP id x17sf305928924oix.2 for ; Mon, 28 Sep 2015 22:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type: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=Zfn0xqAEY5Y72CbB9fh/Oiif9NZ1ixsd1Ft6nSNoQhk=; b=S2VTDwNL8mMZrmhI9eemCYt9heYwAou0Jzg7L4T6buAcrwfwxbgGWinj6DQ9Go5k1r iwn/VUn/rJUYhy/yb9M+OQvqLb9CoWVsdkyk40a7XtiYT36zJRZl1RC+6CYpp4BaJ9yW 9RM935Nta9mCHp1KbnxFQ1M6s/tfR9oP/q9vx/7l9hA2qtOIpFfpwoJZHZAbY2Kkz2nq x6WVl4V75WIs2jrmQcEA8dfUrhHwhN2229MID+nbCwwPxu5MufFZERhjoaR1OZykPCY/ y7HvtAggaTiNCcfKCD2GneQDSTRTpfatl7yho7heIdIxWdw98LCfFI6TssL3H5sYcRR3 3yjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type: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=Zfn0xqAEY5Y72CbB9fh/Oiif9NZ1ixsd1Ft6nSNoQhk=; b=drwVVI9aTpvH72Wmi9VMYQ9m2uBORY6/c24hyuF4V3sHgUryNe0406CY8D0hjWZcqs 6uVf+iNZJebBnszvBhggkayE2kbIf8PYw9cRupKgdHDXxm8d7b+H+aJhWq5WWIcHIarM 2IQ6ON/dDrh0xwkK87UdtbkOBS2VsYMRQjR8Eovd1Tn2Jqgqodc/hoFDwWzXowadzrX7 EuQitS/2qUDL0oywamT/AitNU2D4Y0Rw/sXqLVhCt+GFeDjOGXFF766ocIZ1qTp5KPpk YcDSfIRYlj/bQ6hj7fk7QW2gfxk6xiPnR7MprbQh7yrxrTKUuTJBdX9YFhHSS5MF7Bdc I81w== X-Gm-Message-State: ALoCoQlalBOAkH4dSeVLWs5kO3H/HLLa8bVflKhT7BLQ58+jDEETe/AlAd6eq62Rb6bn/26awKuT X-Received: by 10.182.50.170 with SMTP id d10mr21085278obo.48.1443504435792; Mon, 28 Sep 2015 22:27:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.147.74 with SMTP id ti10ls1042727igb.42.canary; Mon, 28 Sep 2015 22:27:14 -0700 (PDT) X-Received: by 10.50.73.133 with SMTP id l5mr121876igv.14.1443504434842; Mon, 28 Sep 2015 22:27:14 -0700 (PDT) In-Reply-To: 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:20963 Archived-At: ------=_Part_5309_362540967.1443504433630 Content-Type: multipart/alternative; boundary="----=_Part_5310_590883511.1443504433630" ------=_Part_5310_590883511.1443504433630 Content-Type: text/plain; charset=UTF-8 On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote: > > It is a common pattern to declare a local variable of the return type of > the enclosing function, mutate it into the required result, and then return > it... > > std::vector> build_points() { > std::vector> result; > while (c) result.emplace_back(g(c),h(c)); > return result; > } > > First, imagine we defined `auto return` as a kind of decl-specifier that > implied these two things: > > 1. The declared variable has the return type of the enclosing function. > 2. The variable is automatically returned when the function falls off > the end: > That's a combination of two entirely distinct concerns: declaring a variable of a certain type and returning it. I don't see why we need to take two disparate concepts and combine them into one. We already have people tossing around the ability to get a function's return type. That is more generally useful than what you're proposing here, which only allows you to declare variables of that type. And really, you only get to make one. Also, the whole "implicit return" thing sounds like a can of worms. C++ as a language is not required to diagnose failure to return a value from a function with a return value. So if a user takes a quick glance at a function, will they realize you invoked this "implicit return", or will they assume your code is just broken? I'm also not very convinced of your "common pattern" being that common. Or at the very least, it's no less common than computing the value one way or another based on conditional logic. How would such things work with conditional returns? Would you have to structure your code to have all conditionals coalesce at the end? Or would `return` automatically return the value? The ends here do not justify the means. Now suppose we said that this variable could be unnamed, and in such cases > the keyword return could be used as an id-expression to refer to this > return value: > > std::vector> build_points() { > auto return; > while (c) return.emplace_back(g(c),h(c)); > } > Why would you *want* an unnamed variable? Is typing a variable name somehow complicated? Is it an onerous burden for the user? Even in the context of implicit return, using the variable name rather than `return` makes far more sense. Equally importantly, it's really confusing the issue. Are you saying that `return.blah` is an expression or is it a return statement that evaluates and returns an expression? Because the use of the word `return` strongly suggests the latter, not the former. C++ is not Perl. Now suppose we said that if the expression return appears in a function, > the auto return declaration is created implicitly: > > std::vector> build_points() { > while (c) return.emplace_back(g(c),h(c)); > } > Now you've taken away anything that looks even *remotely* like a variable declaration (or C++ in general). This raises a number of questions. Where does this variable get declared? When does its constructor get called? *How* does this variable get declared; does it get default constructed? Is it default initialized or value initialized. What if the type doesn't have a default constructor, or if I want to call a different constructor? What if the default constructor throws; how would you catch the exception? And most importantly, why is this at all worthwhile? Seriously, is declaring a variable and returning it really that hard? The only way I can see this being worthwhile is for code that *would have been* a one-liner, if not for the need to create and return a variable. And quite frankly, that "common pattern" is not *that* common; I imagine most code that needs to declare the return value up front also does a lot more with it than some two-liner. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_5310_590883511.1443504433630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
It is a common= pattern to declare a local variable of the return type of the enclosing fu= nction, mutate it into the required result, and then return it...
=
=C2=A0 std::vector<std::pair<int,int>> build_points() = {
=C2=A0 =C2=A0=C2=A0std::vector<std::pair<int,int>= >=C2=A0result;
=C2=A0 =C2=A0 while (c)=C2=A0result.emplace_bac= k(g(c),h(c));
=C2=A0 =C2=A0 return=C2=A0result;
=C2=A0 }

First, imagine we defined `auto r= eturn` as a kind of decl-specifier that implied these two things:

=C2=A0 1. The declared variable has the return type of the = enclosing function.
=C2=A0 2. The variable is automatically retur= ned when the function falls off the end:

T= hat's a combination of two entirely distinct concerns: declaring a vari= able of a certain type and returning it. I don't see why we need to tak= e two disparate concepts and combine them into one.

We already have = people tossing around the ability to get a function's return type. That= is more generally useful than what you're proposing here, which only a= llows you to declare variables of that type. And really, you only get to ma= ke one.

Also, the whole "implicit return" thing sounds lik= e a can of worms. C++ as a language is not required to diagnose failure to = return a value from a function with a return value. So if a user takes a qu= ick glance at a function, will they realize you invoked this "implicit= return", or will they assume your code is just broken?

I'm= also not very convinced of your "common pattern" being that comm= on. Or at the very least, it's no less common than computing the value = one way or another based on conditional logic. How would such things work w= ith conditional returns? Would you have to structure your code to have all = conditionals coalesce at the end? Or would `return` automatically return th= e value?

The ends here do not justify the means.

Now suppose we said that this variable could be unnamed, and in suc= h cases the keyword return could be used as an id-expression to refer to th= is return value:

=C2=A0 std::vector<std::p= air<int,int>> build_points()=C2=A0{
=C2=A0 =C2=A0 a= uto return;
=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c)= );
=C2=A0 }

Why w= ould you want an unnamed variable? Is typing a variable name somehow= complicated? Is it an onerous burden for the user? Even in the context of = implicit return, using the variable name rather than `return` makes far mor= e sense.

Equally importantly, it's really confusing the issue. A= re you saying that `return.blah` is an expression or is it a return stateme= nt that evaluates and returns an expression? Because the use of the word `r= eturn` strongly suggests the latter, not the former.

C++ is not Perl= ..

Now suppose we said that if the exp= ression return appears in a function, the auto return declaration is create= d implicitly:

=C2=A0 std::vector<std::pair= <int,int>> build_points()=C2=A0{
=C2=A0 =C2=A0 whil= e (c) return.emplace_back(g(c),h(c));
=C2=A0 }
=

Now you've taken away anything that l= ooks even remotely like a variable declaration (or C++ in general). = This raises a number of questions.

Where does this variable get decl= ared? When does its constructor get called? How does this variable g= et declared; does it get default constructed? Is it default initialized or = value initialized. What if the type doesn't have a default constructor,= or if I want to call a different constructor? What if the default construc= tor throws; how would you catch the exception?

And most importantly,= why is this at all worthwhile? Seriously, is declaring a variable and retu= rning it really that hard?

The only way I can see this being worthwh= ile is for code that would have been a one-liner, if not for the nee= d to create and return a variable. And quite frankly, that "common pat= tern" is not that common; I imagine most code that needs to dec= lare the return value up front also does a lot more with it than some two-l= iner.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_5310_590883511.1443504433630-- ------=_Part_5309_362540967.1443504433630-- .