220 21071 <4314af5e-5be2-46d7-a1a6-7928c7555415@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: Wed, 30 Sep 2015 15:52:10 -0700 (PDT) Lines: 247 Approved: news@gmane.org Message-ID: <4314af5e-5be2-46d7-a1a6-7928c7555415@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_7793_1246909813.1443653530901" X-Trace: ger.gmane.org 1443653542 3566 80.91.229.3 (30 Sep 2015 22:52:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 22:52:22 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBHGPWGYAKGQEUL23M5Q@isocpp.org Thu Oct 01 00:52:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZhQEV-0004Ii-MD for gclcip-std-proposals@m.gmane.org; Thu, 01 Oct 2015 00:52:19 +0200 Original-Received: by igcxw12 with SMTP id xw12sf6328085igc.0 for ; Wed, 30 Sep 2015 15:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=v3BcTeE59RbrZojENWRA/KAVlqaxWPe8rDuEYZQYsho=; b=vRryEPlTtShwJ9GxKZrN0OoKOtEC5PQGnwScG5zs0MpZdS2QZpUK2x4Ny4bMo8xN/6 hApYyNfUfv2quhSUVmHdOlVJJAK57vMcdcNMHhqfd9U370xk/aFjIRCTID6l/NGw00UG YAnvn2I6Cz7YNsAfUkutjVF2lMqA7XWGm0WHvPwzU7qqY4jiMch2DNwDac4UxJoJ4cJQ wsF+pyvWePG2x/9QD6+UXZNohsev1ALj84pzvZSuCH6qoZTCs4scnLbcRPY+WSX14Vk5 Hxp8ja9ytXzZMZFbU/cd8ljSB2OKy+yAupa6QxwcAcCB2ScuAK79QDjVXMlalgQGcIsg ouPQ== 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:cc: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=v3BcTeE59RbrZojENWRA/KAVlqaxWPe8rDuEYZQYsho=; b=IjVAXqIBcMFg9pOfDIzTLuonW7WYRtBz4hKZ0BASniGKRnYOsv6ekclewXAIA8mCX5 +wD3S0YJcQg7ROB6+uysDchOjtQQKhT0ZU/dN9ywKk1ocDRAlaYnXPOqQ1xkb7yrdNWA XBxFIEhp+mlfNtDuqplMerzYGO3fukvMt1mc3ak3hxLImtM7T3uOFKeG63whMzQPlrbu 49YgupUhyZBg7nBm2aICsBaDr5uJe2lQN5TPLTP9i0Y1VSIdzm/VTg6qZomr5pjzOlQw mcz1FY7F3gy5W+APpfCyXy+MiEWMgHBZrqdkbm7ZvIhy6z5bu9nKm8qhL3Hk5tHzoTo2 rChA== X-Gm-Message-State: ALoCoQnjhL7Gi+LjPuklI76L799/yI1q/zxf+ZEqOtNrIN6QCnZnwM6QK+YehGiDtr0/1IwynjRD X-Received: by 10.50.114.2 with SMTP id jc2mr28039592igb.5.1443653533222; Wed, 30 Sep 2015 15:52:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.158.79 with SMTP id h76ls439191ioe.104.gmail; Wed, 30 Sep 2015 15:52:11 -0700 (PDT) X-Received: by 10.50.142.9 with SMTP id rs9mr127142igb.6.1443653531979; Wed, 30 Sep 2015 15:52:11 -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:21071 Archived-At: ------=_Part_7793_1246909813.1443653530901 Content-Type: multipart/alternative; boundary="----=_Part_7794_31656051.1443653530902" ------=_Part_7794_31656051.1443653530902 Content-Type: text/plain; charset=UTF-8 On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matthew Woehlke wrote: > > On 2015-09-29 01:27, Nicol Bolas wrote: > > 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. > > ...which, IMO, is a travesty :-). > Can't say I disagree ;) > Well, okay, maybe not that it's not *required*, but that it isn't > commonly *done*. (Is it actually forbidden for a compiler to do so?) > It's not forbidden, and most compilers do it to some degree by default (I think). It's just not a required compile error, since it's possible for valid code to work: int i = val & 0x1; switch(i) { case 0: return ...; case 1: return ...; } //no return Does the user need to write a return statement below there, where logically code will never reach? The question quickly becomes the halting problem. So compilers are required to allow this, only with massive UB if `//no return` is actually encountered. It's the best way to avoid false positives. > I'm also not very convinced of your "common pattern" being that common. > > I've written ' result; ... return result;' often enough that I > wouldn't mind a shortcut. I'd be potentially interested in this much of > the proposal: > > auto foo(...) // arguments not important > { > while (...) > return.emplace_back(...); > return; > } > > That is, one can use 'return' as a local variable; doing so implicitly > declares a mutable 'decltype(return)' variable at the latest point in > the outermost scope in which it is referenced before it is referenced. > If this syntax is used, a 'return' with no value implicitly returns this > implicit result variable (and counts as a reference to the same for the > purpose of the previous rule). > Hmm. The thing about putting the variable at the top is that if it throws on default construction, you haven't broken anything, since the only variables that have been created are the parameters. And sure, everybody ought to be using RAII for exception cleanup (even through GCL's finally stuff). But throwing from the middle of a function, with the source of the exception being an object that has no actual declaration (not to mention the rules you gave about where the variable gets declared)? Isn't that ... dangerously confusing for tracking down errors? > > Or would `return` automatically return the value? > > Yes. > So can you choose to return a different value? > > Why would you *want* an unnamed variable? Is typing a variable name > somehow > > complicated? Is it an onerous burden for the user? > > Yes? :-) (See also requests for anonymous variables for another example > where developers don't want to have to be bothered giving things names.) > The difference is that, in those cases, the anonymous variable can't be referenced. Here it can. Also, in those cases, you may need to create multiple such variables. You can only create one return value. -- --- 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_7794_31656051.1443653530902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matt= hew Woehlke wrote:
On 2015-09-2= 9 01:27, Nicol Bolas wrote:
> Also, the whole "implicit return" thing sounds like a ca= n of worms. C++ as=20
> a language is not required to diagnose failure to return a value f= rom a=20
> function with a return value.

...which, IMO, is a travesty :-).

Can't sa= y I disagree ;)
=C2=A0
Well, okay, maybe not that it's not *required*, but that it isn't
commonly *done*. (Is it actually forbidden for a compiler to do so?)

It's not forbidden, and most compilers do it to = some degree by default (I think). It's just not a required compile erro= r, since it's possible for valid code to work:

int i =3D val & 0x1= ;

<= /span>switch(i)
{
case 0:
=C2=A0 return ...;
case 1:=C2=A0 re= turn ...;
}

//no return

Doe= s the user need to write a return statement below there, where logically co= de will never reach? The question quickly becomes the halting problem. So c= ompilers are required to allow this, only with massive UB if `//no return` = is actually encountered.

It's the best way to avoid false positi= ves.

> I'm also not very convinced of your "common pattern" bei= ng that common.

I've written '<decl> result; ... return result;' ofte= n enough that I
wouldn't mind a shortcut. I'd be potentially interested in this= much of
the proposal:

=C2=A0 auto foo(...) // arguments not important
=C2=A0 {
=C2=A0 =C2=A0 while (...)
=C2=A0 =C2=A0 =C2=A0 return.emplace_back(...);
=C2=A0 =C2=A0 return;
=C2=A0 }

That is, one can use 'return' as a local variable; doing so imp= licitly
declares a mutable 'decltype(return)' variable at the latest po= int in
the outermost scope in which it is referenced before it is referenced.
If this syntax is used, a 'return' with no value implicitly ret= urns this
implicit result variable (and counts as a reference to the same for the
purpose of the previous rule).

Hmm. The thing = about putting the variable at the top is that if it throws on default const= ruction, you haven't broken anything, since the only variables that hav= e been created are the parameters.

And sure, everybody ought to be u= sing RAII for exception cleanup (even through GCL's finally stuff). But= throwing from the middle of a function, with the source of the exception b= eing an object that has no actual declaration (not to mention the rules you= gave about where the variable gets declared)?

Isn't that ... da= ngerously confusing for tracking down errors?
=C2=A0
> Or would `return` automatically return the value?

Yes.

So can you choose to return a different v= alue?
=C2=A0
> Why would you *want* an unnamed variable? Is typing a variable name so= mehow=20
> complicated? Is it an onerous burden for the user?

Yes? :-) (See also requests for anonymous variables for another example
where developers don't want to have to be bothered giving things na= mes.)

The difference is that, in those cases, the = anonymous variable can't be referenced. Here it can. Also, in those cas= es, you may need to create multiple such variables. You can only create one= return value.

--

---
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_7794_31656051.1443653530902-- ------=_Part_7793_1246909813.1443653530901-- .