220 20972 <489434f4-b703-4b0a-ad28-833899af1e14@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: auto return Date: Tue, 29 Sep 2015 07:09:02 -0700 (PDT) Lines: 359 Approved: news@gmane.org Message-ID: <489434f4-b703-4b0a-ad28-833899af1e14@isocpp.org> 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/mixed; boundary="----=_Part_474_163516446.1443535743058" X-Trace: ger.gmane.org 1443535753 22098 80.91.229.3 (29 Sep 2015 14:09:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 14:09:13 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBAFXVKYAKGQERK3ZZ2A@isocpp.org Tue Sep 29 16:09:07 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zgvac-0001mt-IU for gclcip-std-proposals@m.gmane.org; Tue, 29 Sep 2015 16:09:06 +0200 Original-Received: by ykdg206 with SMTP id g206sf8828838ykd.1 for ; Tue, 29 Sep 2015 07:09:05 -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=ozYAzZ39aG99bPKQ37HaEKDD4Z0ynCYlPd9yhBx33Q4=; b=ok1bx+Am8CkgT6erwb2ZCuwvxok2dj8t7nNtS7mzYa+H3MzyfmbghUAthCobSMkDHs mC4V4J/mIxK35x3O3ATgwd+MjbLPFzHcbcx185SKFO+IHmH8+oNS9DPS5Vn4B4KjtJ93 nULlHXmnlYgNesBEPTpf766Hlir5siarGEJ5elmSMEvihbAN9pKOmD1bfkIIhRjZb2T1 nbiDcHGy0o+53ZwSq3XtZ7MiCZlewafrsqwwxmhpRcIlPzGvSGp6cwoEpvDpkp7auKON nl+/kgoHKvSI1GY/RBd3Solp1Qa1tb+V6/vUNs90sNQjQ8T5/MMBs8POPLNzlmTjVOlI zXCA== 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=ozYAzZ39aG99bPKQ37HaEKDD4Z0ynCYlPd9yhBx33Q4=; b=L7TuYQSFDiH4o5nxp2pnNFUTbTauqgkFUp+ndC0kWYLOCB4Gh94Q8+YIqJyg06c4Wh yvRvRqTgLb+AAkwDDnRBkNEFrhOiS6+af3TGRO59igO7jTFZJYHSoX19Tz2MjukvYVft e3AOdHM1XX0ePKCUCaMJcEp25r4FIlqNQsr6WUlRfhbC3i1d2T2yMXtEtKE74GX9O0H0 t6dCts6t2ZIjCb+mKCWPE3ImXfGq2XwALYqV26I7N4q/1S2ltzZit2CSh0wZaLTTgYOA 2C0mqF1VkhlQV8HKpeEcNhrRbRzgXFfQ+1JZWu2X8QtIK/QSGVZcQofpMLGk7AWcnt0D Gwkg== X-Gm-Message-State: ALoCoQkLTfsfeJD9QY/Vf4wpc3AtXDu68ls0/l5gRqkPL/az3z10PYZ4LqmpvJOI0qabHSY1SpkA X-Received: by 10.140.165.83 with SMTP id l80mr23388549qhl.14.1443535745228; Tue, 29 Sep 2015 07:09:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.25.137 with SMTP id 131ls1987406ioz.45.gmail; Tue, 29 Sep 2015 07:09:03 -0700 (PDT) X-Received: by 10.50.62.107 with SMTP id x11mr5123igr.13.1443535743978; Tue, 29 Sep 2015 07:09:03 -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:20972 Archived-At: ------=_Part_474_163516446.1443535743058 Content-Type: multipart/alternative; boundary="----=_Part_475_1419177943.1443535743058" ------=_Part_475_1419177943.1443535743058 Content-Type: text/plain; charset=UTF-8 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/. ------=_Part_475_1419177943.1443535743058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, September 29, 2015 at 2:28: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 wrote:On Tue, Sep 29, 2015 at = 7:27 AM, Nicol Bolas <jmck...@gmail.com> wr= ote:
<= span>
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>> 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 want an unnamed variable? Is typing a variab= le 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.
=C2=A0
There a= re a number of places in the language where an unnamed entity is defined, u= sed or deduced.=C2=A0 I guess the motivation is the same as for those.

For values, yes this is true. Howe= ver, those values are always (as far as I recall) temporaries that d= o not outlive the line in which they are generated. You're talking abou= t 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 stat= ement that evaluates and returns an expression? Because the use of the word= `return` strongly suggests the latter, not the former.
=C2=A0
If you're saying that there is some visual amb= iguity, then that may be so.

Y= es, I was talking about user confusion. But parsing ambiguities don't h= elp your case.

As for parsi= ng ambiguity, return.blah is not one. return.blah is unambiguously an expre= ssion.=C2=A0 The LHS is the id-expression refering to the auto return objec= t.

Let's say we use your s= uggested parsing rule of "if it can be a return statement, it is a ret= urn 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 =3D 5` and you accidentally typed the wrong thing?= If your return type is implicitly convertible from an integer, the compile= r will accept either one. And the two mean very different things, with `ret= urn 5` immediately halting execution.

That is a very nasty, complete= ly silent breakage. That's bad.

FYI: rules like the one y= ou 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&= #39;t be necessary.

There a= re some parsing ambiguities like:

=C2=A0 =C2=A0ret= urn(x);

Is this an expression statement calling op= erator() of the return object, or a return statement returning x.=C2=A0 The= se ambiguities would have to be resolved as part of the proposal (most like= ly "if it can be a return statement, it is a return statement").<= /div>

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 leas= t that may well be a noisy breakage.
=C2=A0
Is it default initialized or val= ue initialized.

It is as-if it was de= clared 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.
or if I want to call a different constructor?

With the third implicit form, you can't.<= /div>
And most importantly, why is th= is at all worthwhile? Seriously, is declaring a variable and returning it r= eally that hard?
=C2=A0
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, lambda= s).

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 sa= id code is, the less likely it is that you will need to use this pat= tern.

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 ra= ther doubt it's even that common), you will save maybe 5% of actual lin= es of text.

So even if this pattern were common, you ultimately don&= #39;t save much. And the downsides of the feature make=C2=A0 it harder to r= eason about code (thanks to `return` ambiguities), introduce unnamed variab= les, and make functions behave in a way that is very new (automatically ret= urning values).

Lambdas save you tons of very difficult-to-write cod= e, especially if they capture values. Thus far, your feature saves you 2 li= nes of trivial-to-write code.

So I'm failing to see the cost/ben= efit 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-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_475_1419177943.1443535743058-- ------=_Part_474_163516446.1443535743058-- .