220 21114 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto return Date: Thu, 01 Oct 2015 12:58:15 -0400 Lines: 119 Approved: news@gmane.org Message-ID: References: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@isocpp.org> <4314af5e-5be2-46d7-a1a6-7928c7555415@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443718722 1610 80.91.229.3 (1 Oct 2015 16:58:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 16:58:42 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBNGMWWYAKGQEFSNMSXI@isocpp.org Thu Oct 01 18:58:33 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f197.google.com ([209.85.217.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZhhBf-0007X8-BP for gclcip-std-proposals@m.gmane.org; Thu, 01 Oct 2015 18:58:31 +0200 Original-Received: by lbbmp1 with SMTP id mp1sf8430953lbb.2 for ; Thu, 01 Oct 2015 09:58:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:content-transfer-encoding:user-agent :in-reply-to: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=6Ovi5CEhmiFk2b5CxpHzAzUrdtq7JU3bZ14FbnUOjkc=; b=lgIVJZInGzq5hJpWvjzFvOKOV07hEBLCv/qbxnHoX+pc7oHCN5az5DILCVIsuS7sil pO4X5oP+uZOwFFiygm2xgqnqC5dVCFX2S6Drc46baId5pSQVs/CSfyksbIYgkSRyfKhU q+bd017otohMCzgjUAS/H18XLWWN206qPXaIvdb8NPWxobemgvJXPpnmZWTeo5zOMIPT zPDZioOR8HI2h4wmriI8whtvelrB5hw8HlwvOV16fLOpMdNbIYcA8IRN63X0do5H8tAr Q5S/FHVwtgbjiVU6GV8KIbQwGmkiDql1ZtzpWI6x/igXQuFvldx X-Gm-Message-State: ALoCoQn60DvEBmCjcaEW61mEEixlyT7wcTn+QVlYeXB0YUuoZWZchBug6JsQIjU4UtfQ72B+6VQN X-Received: by 10.180.35.132 with SMTP id h4mr686234wij.5.1443718709674; Thu, 01 Oct 2015 09:58:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.84.1 with SMTP id i1ls129302lfb.15.gmail; Thu, 01 Oct 2015 09:58:27 -0700 (PDT) X-Received: by 10.112.200.229 with SMTP id jv5mr3381270lbc.123.1443718707626; Thu, 01 Oct 2015 09:58:27 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id py9si3306531lbb.105.2015.10.01.09.58.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 01 Oct 2015 09:58:27 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZhhBa-0007U4-9y for std-proposals@isocpp.org; Thu, 01 Oct 2015 18:58:26 +0200 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Oct 2015 18:58:26 +0200 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Oct 2015 18:58:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 100 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <4314af5e-5be2-46d7-a1a6-7928c7555415@isocpp.org> X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org; dmarc=fail (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:21114 Archived-At: On 2015-09-30 18:52, Nicol Bolas wrote: > On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matthew Woehlke wro= te: >> On 2015-09-29 01:27, Nicol Bolas wrote:=20 >>> Also, the whole "implicit return" thing sounds like a can of=20 >>> worms. C++ as a language is not required to diagnose failure to=20 >>> return a value from afunction with a return value. >>=20 >> ...which, IMO, is a travesty :-). >=20 > Can't say I disagree ;) >=20 >> Well, okay, maybe not that it's not *required*, but that it isn't=20 >> commonly *done*. (Is it actually forbidden for a compiler to do so?) >=20 > It's not forbidden, and most compilers do it to some degree by default (I= =20 > think). At least gcc 4.8 doesn't make it an error by default; AFAIK that hasn't changed, nor does clang make it an error either. I'm not sure MSVC even has a warning. > It's just not a required compile error, since it's possible for=20 > valid code to work: >=20 > int i =3D val & 0x1; >=20 > switch(i) > { > case 0: > return ...; > case 1: > return ...; > } >=20 > //no return First, to be clear, I'm not talking about cases where the last line in a function is other than 'return'. I'm talking about cases where the compiler determines that some plausible code path will result in execution falling off the end of the function. This would exclude your above example, and also e.g. code paths that dive into a [[noreturn]] function. Getting that right seems like a QoI issue, and modern compilers seem to already do a good job here. Moreover, I would expect compilers to err on the side of caution and not issue a fatal diagnostic if they aren't confident that there is really a problem. (Mind, I've personally used -Werror=3Dreturn-type for some years now on pretty much any software I build, and have yet to see a false positive.) I wouldn't anyway propose to *mandate* a diagnostic, because it *is* a hard problem to get right. I just wish compilers would default to making this an error rather than a warning, especially in pathological cases such as a function that can't *not* fall off the end (e.g. because it contains no 'return' or [[noreturn]] calls *at all*)=C2=B9. And yes, I've seen these in real code. (I'd even hazard to say that those are the *majority* of the -Werror=3Dreturn-type errors I've seen, and from functions with only a few lines of code in their bodies.) (=C2=B9 I suppose you could have a function that is guaranteed to throw... but if so, why is the return type non-void?) Anyway, this is all fascinating, but OT :-). >>> I'm also not very convinced of your "common pattern" being that common.= =20 >> >> [...] one can use 'return' as a local variable; doing so implicitly=20 >> declares a mutable 'decltype(return)' variable at the latest point in=20 >> the outermost scope in which it is referenced before it is referenced.= =20 >> If this syntax is used, a 'return' with no value implicitly returns this= =20 >> implicit result variable (and counts as a reference to the same for the= =20 >> purpose of the previous rule). >=20 > Hmm. The thing about putting the variable at the top is that if it throws= =20 > on default construction, you haven't broken anything, since the only=20 > variables that have been created are the parameters. Hmm, true, but OTOH if construction is expensive and you don't need it until halfway through the function (after a bunch of other logic that might early exit and return something else), then you've constructed and destroyed an unused local for no reason. > Isn't that ... dangerously confusing for tracking down errors? You could always just not use exceptions? ;-) That said, I can agree that's an issue. This is another feature that I think would be nice and useful *if* we had it, but probably not worth trying to standardize. >>> Or would `return` automatically return the value?=20 >> >> Yes. >=20 > So can you choose to return a different value? Yes. (The above might be unclear; "return;" - with no 'argument' - returns the implicit result variable, "return ;" returns "".) --=20 Matthew --=20 ---=20 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 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/group/std-proposa= ls/. .