220 21063 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto return Date: Wed, 30 Sep 2015 15:30:57 -0400 Lines: 114 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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1443641501 6001 80.91.229.3 (30 Sep 2015 19:31:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 19:31:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBC7RWCYAKGQEYNIYE3Y@isocpp.org Wed Sep 30 21:31:33 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZhN66-0005fh-7c for gclcip-std-proposals@m.gmane.org; Wed, 30 Sep 2015 21:31:26 +0200 Original-Received: by wicgb1 with SMTP id gb1sf27998231wic.3 for ; Wed, 30 Sep 2015 12:31:24 -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: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=NOKReHQD9Ss4CyqZ4Kpeud06XV2d8xux+fWDPb2R9bI=; b=jrhVryDbsMrDfRewWyPDxiXrBQHT3FC7taqvQvSjh1o8GZADJ1mlS2vs/fj8jxYBa+ 6ADqBA8VPAQdnwCpX2tKAt/tSCDQdl6y16yxNcIiYGrdi0i7AQp2BNA0aTC0CYEU6d56 pIrqXPqivv3LLV5xuOH9zrejLNsN0vmfYtPhk8h0RWfgEPEW+0RhhVNMXqipbfHKPxQw dMUqM1nDzXlEzghwur5JhJrLCa2Dc4yB0x7DMZIq/1olFlSCWbJQg5x4BD70s/VSAAd5 XO7haBAoUMnnNDEdVHfMo62ldmC9U9S/CLtCHCCNKxjJFiG7BVW5sou3RxkYxOOq1Dl1 X-Gm-Message-State: ALoCoQlBEQyP/EE781deEodtpdjEM8MyS1tKeTuSa0jkVzJitvb3jO+/FY280Q0M6SzmfgtCeIMt X-Received: by 10.180.72.68 with SMTP id b4mr945921wiv.2.1443641484654; Wed, 30 Sep 2015 12:31:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.21.166 with SMTP id 38ls74244lfv.22.gmail; Wed, 30 Sep 2015 12:31:23 -0700 (PDT) X-Received: by 10.152.3.196 with SMTP id e4mr1691794lae.68.1443641483193; Wed, 30 Sep 2015 12:31:23 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id y6si928689lal.172.2015.09.30.12.31.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Sep 2015 12:31:23 -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 1ZhN61-0005d5-HT for std-proposals@isocpp.org; Wed, 30 Sep 2015 21:31:21 +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 ; Wed, 30 Sep 2015 21:31:21 +0200 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Sep 2015 21:31:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 105 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: <7deedcff-6776-4b3b-a3d1-3132f8ec1ae3@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:21063 Archived-At: 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 :-). 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?) IMO, -Werror=return-type ought to be default behavior. Back on topic, I agree that implicit returns sound horrible... > 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). That said, it would be much better (and I would prefer) if the implicit variable could be named something like '__result'... > How would such things work with conditional returns? Would you have > to structure your code to have all conditionals coalesce at the end? No. An explicit 'return' is still required. You can explicitly return anything, at any point, as always. > Or would `return` automatically return the value? Yes. > 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.) Declaring and naming the temporary variable used to aggregate the result is unnecessary overhead. > On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote: >> 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? When does its constructor get > called? See above. > *How* does this variable get declared; does it get default > constructed? Yes. (Well, "like 'auto&& __result = decltype(return){}" would be fine, just so long as it isn't trying to call some non-obvious ctor.) > Is it default initialized or value initialized. What if the > type doesn't have a default constructor, or if I want to call a different > constructor? Don't use this feature for those cases. In such cases, you need an explicit declaration anyway, so the feature (assuming we get 'decltype(return)') is of minimal benefit. > What if the default constructor throws; how would you catch > the exception? Wrap any reference to it in a try-catch, so that the declaration scope is the 'try { ... }'. The technical problems seem solvable. Does seem like a lot of effort for the benefit, though. On 2015-09-29 10:09, Nicol Bolas wrote: > You're talking about deliberately declaring an unnamed *variable*. > That's very new for C++. ....but *not* the first time it's been requested. (OT: And, really... having to name variables that exist only for the side effects of their ctor/dtor *is* annoying...) -- Matthew -- --- 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/. .