220 24175 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Change the specified behavior when control flow reaches the end of non-void functions Date: Wed, 03 Feb 2016 15:22:28 -0500 Lines: 56 Approved: news@gmane.org Message-ID: References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> <3004028.jdIGuf4xbV@tjmaciei-mobl4> <2abab9c9-8151-4187-af5c-2ffc522ab747@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 1454530965 18272 80.91.229.3 (3 Feb 2016 20:22:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 20:22:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBC6DZG2QKGQE2UU77VI@isocpp.org Wed Feb 03 21:22:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aR3wj-0007id-BX for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 21:22:37 +0100 Original-Received: by mail-wm0-f70.google.com with SMTP id l66sf32961563wml.1 for ; Wed, 03 Feb 2016 12:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=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=Jsy+UD/4YTjrLON939lKuO3hEkfO9K504QBrbLLBi6Y=; b=ftDsip4+gkueEJ0v/Xgyq+VNlFe9dYpk44ZoGh2dJ0x+lVEXn/g9NwnXM5sX2CcjF8 Q7UkSpSQmwXdbLpqj4jzsuFPmIa47nOJL176kcKSP+z5aJO0fWneCb5mrJUiztP72yPU qKZbUQVRywWeGRWK6N0Se7RrQV5ta9GBE8UYoN/2PeR8rzX1T9MIJ8i6jQobePk8mjPM 41UTVnimyWEkqN8cY19p4iL8V4DkdbrSwiu2D+UKyKIMiJbeYKpXZz31W8XI0nc3i98E xilfoQYHpMgDwWLltUq9FUl/u1tntH5X2F/Biy7snlywbI2jSOUcS6rWPajwxwNGNkmC 53C 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=Jsy+UD/4YTjrLON939lKuO3hEkfO9K504QBrbLLBi6Y=; b=BweB1qegkrT1Y5c9M88H1njRtzOSURE/GvDlmMapAd4V1pa5iN5lLUDSQGKYgo3izV n+45nhJi/BYssHEXRR7rm/cwOZyLBDjyEo4oYEuMJ/lRA7HU+FY8fpNhTj/EtU+Jrd2W CuOZbgQjpAIou8a6yuRD4STop/2KMvbC2BpyDSpmikalRxYqx6t5NTlYqtElumtxLPeT o1T4V/k6oP01g7qwmooT/tPlSDZXXJNobsacEafQ8irj1EaL3LV5VmTgeOxhH1oCPKxW VdQK4U4SDW2XeTipebYqjOA6L/U/V4H8BNH6ykkglT2IVvPRUNxyG3EDBS46K66JVvP4 X-Gm-Message-State: AG10YOQdUPBjucF6tZB0SBaaTCTGrmxyoLSFd79FXTTD/md59hntr6Qlx0f/v0dpE4EiAg== X-Received: by 10.112.72.195 with SMTP id f3mr601682lbv.15.1454530956859; Wed, 03 Feb 2016 12:22:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.162.203 with SMTP id l194ls163274lfe.107.gmail; Wed, 03 Feb 2016 12:22:35 -0800 (PST) X-Received: by 10.25.209.80 with SMTP id i77mr1744957lfg.33.1454530955165; Wed, 03 Feb 2016 12:22:35 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id qa1si5070315lbb.195.2016.02.03.12.22.35 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 03 Feb 2016 12:22:35 -0800 (PST) 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 1aR3wg-0007gQ-7b for std-proposals@isocpp.org; Wed, 03 Feb 2016 21:22:34 +0100 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, 03 Feb 2016 21:22:34 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Feb 2016 21:22:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 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: <2abab9c9-8151-4187-af5c-2ffc522ab747@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:24175 Archived-At: On 2016-02-03 14:41, Nicol Bolas wrote: > If I'm writing code where a set of conditions is always supposed to be > true, such that no runtime codepath can ever reach the end of the function, > and I *screw this up* in some way, `std::terminate` has value. It causes my > program to blow up when that runtime state is reached. > > Your way prevents me from writing it *even if* I do it correctly. The fact > that I could have screwed it up doesn't mean I *did*. Wrong; you can write such code by inserting an explicit std::terminate. This ends up working *exactly* like John is proposing, but with the added benefit that the code has been visibly annotated. (Better would be to have a standardized "unreachable" annotation; all the same benefits, *plus* compiler optimization opportunities, on top of said annotation having additional use cases.) This is what I mean by laziness... we all know (at least, I hope) that it's better to catch errors at compile time rather than run time. The only reason I see to have an implicit terminate rather than a compile error is because *we are too lazy* to a) standardize unreachability and b) make use of the same. (Somewhat off-topic; it may be reasonable for unused - and not visible outside the TU - functions to be exempt from these checks. Although probably this is best handled per compiler by suppressing problems from such "orphan" functions, besides a warning about them being orphans.) > Your way is not "perfect" No, and I didn't mean to imply that it was. It's just "better". Same end result, but code is annotated and mistakes can be caught at compile time, not run time. Moreover, if the compiler *can* prove that code annotated unreachable can in fact be reached, it can make that a compile error as well. To reiterate a point I made previously, I consider it unacceptable that this code is valid: int foo() {} // note empty body Any proposal that does not make this ill-formed has (IMO) not gone far enough. "Marginally adequate" can *also* be the enemy of "good". -- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. .