220 20965 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: auto return Date: Tue, 29 Sep 2015 08:28:54 +0200 Lines: 395 Approved: news@gmane.org Message-ID: References: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1130cc429c918d0520dced36 X-Trace: ger.gmane.org 1443508139 28496 80.91.229.3 (29 Sep 2015 06:28:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 06:28:59 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBD5KHQXXWYPRBJ67VCYAKGQEMQNPWBI@isocpp.org Tue Sep 29 08:28:59 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f199.google.com ([209.85.212.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZgoPK-0001ZV-R4 for gclcip-std-proposals@m.gmane.org; Tue, 29 Sep 2015 08:28:58 +0200 Original-Received: by wicgb1 with SMTP id gb1sf25656wic.3 for ; Mon, 28 Sep 2015 23:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SkJdQ5X1KMry7W561h7sLIjttMYtW+Fmn73HuxcFKGY=; b=bDBZl9TAzHLVELqIOl672hQ2Q53TSp17Y0N7WjxMtKrOFIqc7rLruTs36ihQEy9VQK DmaoCip6Aldhggs0sKrlp8VC9+tKdlEsXa8uFBnarnPZbTv75EgNrInXo7GBdorL+pUV iICUhfgefIUHAteE8CDk/ra5lEm1bbyt1Oy7D6ljx43uu/uQARI/NYvzSsOFr0NKLo+2 y/wr4c2u5x7DFFNVVuUs3d3XnRK2NNu6YZBoySlpkukh4iCm5e8malBbUcFW8T0BSg2Y BXr5CdqQSgOCQ6JO2ML7e128TuaUARoNweWk/4nsl1Oa3UkhUL+xhilqrQZuHW5ilaMv 1b5g== X-Gm-Message-State: ALoCoQkFW+WG1e5wKA9nPDNHxoO9qh491st04NyOEIGFPKFSLUvHKHbgMH63EjIIzCiU61wS4LII X-Received: by 10.152.197.34 with SMTP id ir2mr189480lac.10.1443508138120; Mon, 28 Sep 2015 23:28:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.89.102 with SMTP id bn6ls699453wib.43.canary; Mon, 28 Sep 2015 23:28:55 -0700 (PDT) X-Received: by 10.194.206.38 with SMTP id ll6mr16385460wjc.116.1443508135107; Mon, 28 Sep 2015 23:28:55 -0700 (PDT) Original-Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com. [2a00:1450:400c:c05::233]) by mx.google.com with ESMTPS id om11si27353168wic.29.2015.09.28.23.28.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 23:28:55 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::233 as permitted sender) client-ip=2a00:1450:400c:c05::233; Original-Received: by wicfx3 with SMTP id fx3so169896wic.0 for ; Mon, 28 Sep 2015 23:28:55 -0700 (PDT) X-Received: by 10.194.113.131 with SMTP id iy3mr6296157wjb.152.1443508134906; Mon, 28 Sep 2015 23:28:54 -0700 (PDT) Original-Received: by 10.28.73.137 with HTTP; Mon, 28 Sep 2015 23:28:54 -0700 (PDT) In-Reply-To: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> X-Original-Sender: andrewtomazos@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::233 as permitted sender) smtp.mailfrom=andrewtomazos@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:20965 Archived-At: --001a1130cc429c918d0520dced36 Content-Type: text/plain; charset=UTF-8 Thanks for your feedback. Questions answered below.. On Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas wrote: > 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? > While forgetting to return from a value-returning function is technically UB, there is a defacto standard warning that every implementation has to diagnose such cases. 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? > I'm not sure what a conditional return is. If you are returning one of multiple different expressions (or anything other than an id-expression to a single return object) then I think you would do it the normal way. The proposed feature is purely for the pattern where you construct the result object at the start of the function and then mutate it throughout the function. 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. > There are a number of places in the language where an unnamed entity is defined, used or deduced. I guess the motivation is the same as for those. 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. > If you're saying that there is some visual ambiguity, then that may be so. As for parsing ambiguity, return.blah is not one. return.blah is unambiguously an expression. The LHS is the id-expression refering to the auto return object. There are some parsing ambiguities like: return(x); Is this an expression statement calling operator() of the return object, or a return statement returning x. These ambiguities would have to be resolved as part of the proposal (most likely "if it can be a return statement, it is a return statement"). 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? > An auto return declaration statement is inserted implicitly at the start of the function definition (if a return id-expression appears in the function definition). > When does its constructor get called? > At the start of the function. > *How* does this variable get declared; does it get default constructed? > Yes. > Is it default initialized or value initialized. > It is as-if it was declared without an initializer: T f() { T x; // <-- like this I can't remember which this implies off the top of my head. What if the type doesn't have a default constructor, > Ill-formed. > or if I want to call a different constructor? > With the third implicit form, you can't. With the second unnamed form maybe we could say: auto return(1,2,3); is ok. That is, it can be trailed with an initializer. > What if the default constructor throws; how would you catch the exception? > I can't remember if this works: void f() { return++; } catch (...) { } But if it does, it would catch an exception thrown from the return constructor. Otherwise, you can't catch it. (I'm not sure what you plan to return if a default constructed return value of your function throws.) And most importantly, why is this at all worthwhile? Seriously, is > declaring a variable and returning it really that hard? > The motivation is mainly providing a terser syntax for an, in my opinion, common pattern (as an example, a similar motivation to, although much smaller than, lambdas). If you don't think the pattern is common I can see how it would follow that you think it isn't worthwhile. 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/. > -- --- 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/. --001a1130cc429c918d0520dced36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your feedback.=C2=A0 Questions answered below..=

On Tue, Sep 2= 9, 2015 at 7:27 AM, Nicol Bolas <jmckesson@gmail.com> wrot= e:
On Tuesday, September= 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:
It is a common pattern to declare a loca= l variable of the return type of the enclosing function, 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=A0= std::vector<std::pair<int,int>>=C2=A0result;
=C2=A0 = =C2=A0 while (c)=C2=A0result.emplace_back(g(c),h(c));
=C2=A0 =C2= =A0 return=C2=A0result;
=C2=A0 }

First, imagine we defined `auto return` 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 returned when the function falls off the end= :

That's a combination of two e= ntirely distinct concerns: declaring a variable of a certain type and retur= ning it. I don't see why we need to take two disparate concepts and com= bine them into one.

We already have people tossing around the abilit= y to get a function's return type. That is more generally useful than w= hat you're proposing here, which only allows you to declare variables o= f that type. And really, you only get to make one.

Also, the whole &= quot;implicit return" thing sounds like a can of worms. C++ as a langu= age is not required to diagnose failure to return a value from a function w= ith a return value. So if a user takes a quick glance at a function, will t= hey realize you invoked this "implicit return", or will they assu= me your code is just broken?
=C2=A0
Wh= ile forgetting to return from a value-returning function is technically UB,= there is a defacto standard warning that every implementation has to diagn= ose such cases.

I&#= 39;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 va= lue one way or another based on conditional logic. How would such things wo= rk with conditional returns? Would you have to structure your code to have = all conditionals coalesce at the end? Or would `return` automatically retur= n the value?
=C2=A0
I'm not sure w= hat a conditional return is.=C2=A0 If you are returning one of multiple dif= ferent expressions (or anything other than an id-expression to a single ret= urn object) then I think you would do it the normal way.=C2=A0 The proposed= feature is purely for the pattern where you construct the result object at= the start of the function and then mutate it throughout the function.

The ends here do not ju= stify 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:
=
=C2=A0 std::vector<std::pair<int,int>> buil= d_points()=C2=A0{
=C2=A0 =C2=A0 auto return;
=C2=A0 =C2= =A0 while (c) return.emplace_back(g(c),h(c));
=C2=A0 }
<= /div>

Why would you want an unname= d 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 var= iable name rather than `return` makes far more sense.
=C2=A0
There are a number of places in the language where a= n unnamed entity is defined, used or deduced.=C2=A0 I guess the motivation = is the same as for those.

C++= is not Perl.

Now suppose= we said that if the expression return appears in a function, the auto retu= rn declaration is created implicitly:

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

Now you've take= n 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?

An auto = return declaration statement is inserted implicitly at the start of the fun= ction definition (if a return id-expression appears in the function definit= ion).=C2=A0
=C2=A0=C2=A0
When does its constructor get called?

At the start of the function.
=C2=A0
How does this variable get declared; does it get def= ault constructed?

Yes.
=C2= =A0
Is it default initialized or v= alue initialized.

It is as-if it was = declared without an initializer:

=C2=A0 T f() {
=C2=A0 =C2=A0 T x; =C2=A0// <-- like this
=C2=A0
=
I can't remember which this implies off the top of my head.
<= div>
What if the type doesn&#= 39;t have a default constructor,

Ill-= formed.
=C2=A0
or if I = want to call a different constructor?

With the third implicit form, you can't.=C2=A0 With the second unname= d form maybe we could say:

=C2=A0 =C2=A0auto retur= n(1,2,3);

is ok.=C2=A0 That is, it can be trailed = with an initializer.
=C2=A0
What if the default constructor throws; how would you catch the exc= eption?

I can't remember if t= his works:

=C2=A0 =C2=A0 void f() {
=C2= =A0 =C2=A0 =C2=A0 return++;
=C2=A0 =C2=A0 } catch (...) {
=C2=A0 =C2=A0 }

But if it does, it would catch = an exception thrown from the return constructor.

O= therwise, you can't catch it. =C2=A0(I'm not sure what you plan to = return if a default constructed return value of your function throws.)

And most importantly, w= hy is this at all worthwhile? Seriously, is declaring a variable and return= ing it really that hard?
=C2=A0
The mo= tivation is mainly providing a terser syntax for an, in my opinion, common = pattern (as an example, a similar motivation to, although much smaller than= , lambdas).=C2=A0 If you don't think the pattern is common I can see ho= w it would follow that you think it isn't worthwhile.

The only way I can see this being wo= rthwhile is for code that would have been a one-liner, if not for th= e need to create and return a variable. And quite frankly, that "commo= n pattern" is not that common; I imagine most code that needs t= o 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 &= 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-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>.
--001a1130cc429c918d0520dced36-- .