220 20990 article Path: news.gmane.org!not-for-mail From: little3lue Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: auto return Date: Tue, 29 Sep 2015 20:08:40 +0000 Lines: 418 Approved: news@gmane.org Message-ID: References: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> <489434f4-b703-4b0a-ad28-833899af1e14@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c032818e9255d0520e8613a X-Trace: ger.gmane.org 1443557339 22366 80.91.229.3 (29 Sep 2015 20:08:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 20:08:59 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC46VCEIWUFBBU67VOYAKGQEYKXNISI@isocpp.org Tue Sep 29 22:08:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zh1Co-0000hy-OU for gclcip-std-proposals@m.gmane.org; Tue, 29 Sep 2015 22:08:55 +0200 Original-Received: by vkgd64 with SMTP id d64sf22818471vkg.2 for ; Tue, 29 Sep 2015 13:08:53 -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:references:in-reply-to:from:date :message-id:subject: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=YfE6i+f/updo6D4LuAko/P4lu7Sf4A3RFAPH4CPRCBc=; b=Mk7BSrdxNbsn1l2WWM8rvhtizAZtA3ze2du8HbwPGQOwToSsL/JNooGCkFVH9AlY4j ogmSboj8THLV1ThNx3sWMhtyp6KzOCj8dLfTwMgSci3WN7LosazS7pZyAPzkJW6gtnhP NX+eKarGcM3jp5blDde0nVcYHjPxcMMhNA/2fFzQcBDxXQU/KAZ404MI0EwX2xPb4P9i d4dFhN8VN7z/AfHONgWP3h1Uk381Y6TgJj0o5rvfZKNlf78vSD1EC2PONs+cLHWzDKFg yTf3gjnazAojb/Pi/dQkGz2ebHru5UxUqRqVS85QRvrRe3CZqW1OJsjLuG/PqzADVpFl ETsA== X-Gm-Message-State: ALoCoQnW0cVV+IjPkOxUpCmBkPKzc03OIn8YSzwQEnIRmqEIIa2Y6VXUZK6I7Z9Ho75TP+Z+b9Mk X-Received: by 10.31.3.93 with SMTP id 90mr24946233vkd.0.1443557333660; Tue, 29 Sep 2015 13:08:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.22.135 with SMTP id 7ls7134qgn.58.gmail; Tue, 29 Sep 2015 13:08:51 -0700 (PDT) X-Received: by 10.170.215.195 with SMTP id h186mr23309342ykf.126.1443557331144; Tue, 29 Sep 2015 13:08:51 -0700 (PDT) Original-Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com. [2607:f8b0:4002:c07::233]) by mx.google.com with ESMTPS id x81si12491547ywc.185.2015.09.29.13.08.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 13:08:51 -0700 (PDT) Received-SPF: pass (google.com: domain of little3lue@gmail.com designates 2607:f8b0:4002:c07::233 as permitted sender) client-ip=2607:f8b0:4002:c07::233; Original-Received: by ykdt18 with SMTP id t18so18656190ykd.3 for ; Tue, 29 Sep 2015 13:08:50 -0700 (PDT) X-Received: by 10.13.240.71 with SMTP id z68mr23970066ywe.65.1443557330722; Tue, 29 Sep 2015 13:08:50 -0700 (PDT) In-Reply-To: <489434f4-b703-4b0a-ad28-833899af1e14@isocpp.org> X-Original-Sender: LittLe3Lue@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of little3lue@gmail.com designates 2607:f8b0:4002:c07::233 as permitted sender) smtp.mailfrom=little3lue@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:20990 Archived-At: --94eb2c032818e9255d0520e8613a Content-Type: text/plain; charset=UTF-8 Some languages allow creating a named variable for the return type, as part of the function definition. E.g. strawman: // foo.h Foo getFoo(); // foo.cpp (Foo foo) getFoo() { // foo is initialized and "automatically returned" unless another value is explicitly returned foo.fizzle(); } // Or maybe: auto getFoo -> Foo foo { } -Michal On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas wrote: > On Tuesday, September 29, 2015 at 2:28:58 AM UTC-4, Andrew Tomazos wrote: >> >> Thanks for your feedback. Questions answered below.. >> > >> On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:On >>> Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas wrote: >>> >> 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. >> > > For values, yes this is true. However, those values are always (as far as > I recall) *temporaries* that do not outlive the line in which they are > generated. You're talking about deliberately declaring an unnamed > *variable*. > > That's very new for C++. > > 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. >> > > Yes, I was talking about user confusion. But parsing ambiguities don't > help your case. > > 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. >> > > Let's say we use your suggested parsing rule of "if it can be a return > statement, it is a return statement". > > So let's consider `return 5;`. That's a return statement. But did you > *mean* for it to be a return statement? Or did you mean `return = 5` and > you accidentally typed the wrong thing? If your return type is implicitly > convertible from an integer, the compiler will accept either one. And the > two mean very different things, with `return 5` immediately halting > execution. > > That is a very nasty, completely *silent* breakage. That's bad. > > FYI: rules like the one you suggest gave us the Most Vexing Parse > . We should not > deliberately add features like that again. > > If you had just introduced an actual name, that wouldn't be necessary. > > 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"). >> > > Which would limit the ways in which you can use this implicit variable. > You can't even call operator() on it without shenanigans (like `(return)()` > or whatever). Though at least that may well be a noisy breakage. > > >> 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. >> > > That's default initialization > , so > for many types, they go uninitialized. That's generally considered bad > these days. Or at least, it's not good for it to be the default case. > > 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. >> > > Doesn't this restriction significantly limit how much users can use this > "common pattern"? Even if only 30% of uses of this pattern used a > non-default constructor, that's still almost 1/3rd of potential users who > can't use this feature. > > So ultimately, all they save is a return at the bottom of the function. > Again, is that *one line* worth the syntactic burden? > > >> 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. >> > > Well, that particular syntax doesn't work. But it is possible to create function-level > try/catch blocks > . > > But really, you shouldn't encourage that. > > >> 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). >> > > You're saving 2 lines of code. In a function that's just 10 lines long > (including declaration and {}s), that's only a 20% reduction in code size. > And the shorter said code is, the *less* likely it is that you will need > to use this pattern. > > And you can only save two lines of code if you use the > default-construct-followed-by-initialization pattern. If you need to use an > actual constructor, you save... one line of code. Only 10% in a 10 line > function. > > If a full quarter of your functions use the first pattern (and I rather > doubt it's even that common), you will save maybe 5% of actual lines of > text. > > So even if this pattern were common, you ultimately don't save much. And > the downsides of the feature make it harder to reason about code (thanks > to `return` ambiguities), introduce unnamed variables, and make functions > behave in a way that is very new (automatically returning values). > > Lambdas save you tons of very difficult-to-write code, especially if they > capture values. Thus far, your feature saves you 2 lines of > trivial-to-write code. > > So I'm failing to see the cost/benefit here. > > -- > > --- > 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/. --94eb2c032818e9255d0520e8613a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some languages allow creating a named variable for the ret= urn type, as part of the function definition.

E.g. straw= man:

// foo.h
Foo getFoo();
// foo.cpp
(Foo foo) getFoo() {
=C2=A0 // = foo is initialized and "automatically returned" unless another va= lue is explicitly returned
=C2=A0 foo.fizzle();
}
=

// Or maybe:
auto getFoo -> Foo foo {
}

-Michal

On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas <<= a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com> wrote:
On Tuesday, September 29, 2015 at 2:2= 8:58 AM UTC-4, Andrew Tomazos wrote:
Thanks for your feedback.=C2=A0 Questions answered below.= ..

On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wro= te:On Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas &l= t;jmck...@gmail.com> wrote:
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 va= lue:

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

Why would you wa= nt an unnamed variable? Is typing a variable name somehow complicated? = Is it an onerous burden for the user? Even in the context of implicit retur= n, using the variable name rather than `return` makes far more sense.
=C2=A0
There are a number of places in the = language where an unnamed entity is defined, used or deduced.=C2=A0 I guess= the motivation is the same as for those.

For values, yes this is true. However, those values are always= (as far as I recall) temporaries that do not outlive the line in wh= ich they are generated. You're talking about deliberately declaring an = unnamed variable.

That's very new for C++.

<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
Equally importa= ntly, 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 a= n expression? Because the use of the word `return` strongly suggests the la= tter, not the former.
=C2=A0
If you= 9;re saying that there is some visual ambiguity, then that may be so.
=

Yes, I was talking about user confu= sion. But parsing ambiguities don't help your case.

As for parsing ambiguity, return.blah is not one. r= eturn.blah is unambiguously an expression.=C2=A0 The LHS is the id-expressi= on refering to the auto return object.
=

Let's say we use your suggested parsing rule of "if it ca= n be a return statement, it is a return statement".

So let'= s consider `return 5;`. That's a return statement. But did you mean<= /i> for it to be a return statement? Or did you mean `return =3D 5` and you= accidentally typed the wrong thing? If your return type is implicitly conv= ertible from an integer, the compiler will accept either one. And the two m= ean very different things, with `return 5` immediately halting execution.
That is a very nasty, completely silent breakage. That's b= ad.

FYI: rules like the one you suggest gave us the Most Vexing P= arse. We should not deliberately add features like that again.

I= f you had just introduced an actual name, that wouldn't be necessary.
<= div class=3D"gmail_quote">
There are some parsing ambiguitie= s like:

=C2=A0 =C2=A0return(x);

Is this an expression statement calling operator() of the return obj= ect, or a return statement returning x.=C2=A0 These ambiguities would have = to be resolved as part of the proposal (most likely "if it can be a re= turn statement, it is a return statement").

Which would limit the ways in which you can use this imp= licit variable. You can't even call operator() on it without shenanigan= s (like `(return)()` or whatever). Though at least that may well be a noisy= breakage.
=C2=A0
Is it default initialized or value 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 whic= h this implies off the top of my head.
=

That's default initialization, so for = many types, they go uninitialized. That's generally considered bad thes= e days. Or at least, it's not good for it to be the default case.
What = if the type doesn't have a default constructor,
=
Ill-formed.
=C2=A0
or if I w= ant to call a different constructor?

With the third implicit form, you can't.

Doesn't this restriction significantly limit how much u= sers can use this "common pattern"? Even if only 30% of uses of t= his pattern used a non-default constructor, that's still almost 1/3rd o= f potential users who can't use this feature.

So ultimately, all= they save is a return at the bottom of the function. Again, is that one= line worth the syntactic burden?
=C2=A0
What if the default constructor thro= ws; how would you catch the exception?

I can't remember if this 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 construc= tor.

Well, that particular syn= tax doesn't work. But it is possible to create function= -level try/catch blocks.

But really, you shouldn't encourage= that.
=C2=A0
And most importantly, why is this at all worthwhile? Ser= iously, is declaring a variable and returning it really that hard?
=C2=A0
The motivation is mainly providing a te= rser syntax for an, in my opinion, common pattern (as an example, a similar= motivation to, although much smaller than, lambdas).

You're saving 2 lines of code. In a function th= at's just 10 lines long (including declaration and {}s), that's onl= y a 20% reduction in code size. And the shorter said code is, the less likely it is that you will need to use this pattern.

And you can = only save two lines of code if you use the default-construct-followed-by-in= itialization pattern. If you need to use an actual constructor, you save...= one line of code. Only 10% in a 10 line function.

If a full quarter= of your functions use the first pattern (and I rather doubt it's even = that common), you will save maybe 5% of actual lines of text.

So eve= n if this pattern were common, you ultimately don't save much. And the = downsides of the feature make=C2=A0 it harder to reason about code (thanks = to `return` ambiguities), introduce unnamed variables, and make functions b= ehave in a way that is very new (automatically returning values).

La= mbdas save you tons of very difficult-to-write code, especially if they cap= ture values. Thus far, your feature saves you 2 lines of trivial-to-write c= ode.

So I'm failing to see the cost/benefit here.

--

---
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>.
--94eb2c032818e9255d0520e8613a-- .