220 24173 <2abab9c9-8151-4187-af5c-2ffc522ab747@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas 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, 3 Feb 2016 11:41:39 -0800 (PST) Lines: 249 Approved: news@gmane.org Message-ID: <2abab9c9-8151-4187-af5c-2ffc522ab747@isocpp.org> References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> <3004028.jdIGuf4xbV@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7712_275069644.1454528499408" X-Trace: ger.gmane.org 1454528507 10562 80.91.229.3 (3 Feb 2016 19:41:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 19:41:47 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB5FPZG2QKGQEWR3BZSI@isocpp.org Wed Feb 03 20:41:43 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aR3J8-0000T6-LW for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 20:41:42 +0100 Original-Received: by mail-qg0-f69.google.com with SMTP id u30sf30762156qge.0 for ; Wed, 03 Feb 2016 11:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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=jLE+aas1zBHeNiW27ms2A+nAzVwCjfFwAHlElUgwHkU=; b=vmq9kQbNlelL/XTNO8/VFAjXxOV5tmFaeTCbr022QT02ODlQBHW8qdsLwOC7jnh4U3 OuZ7f/7+6Tya89Xu5Vxgmu1xgll9omVsTx8u58UR6yUBqyATwdePEt7xX1CPWJVvUmn9 6LoScY2DQRTFca8DLBTFiNZDEUpiK6VFch2N0PgA8BWdeN82D/pkq8kveVx9/IfRcJX8 1FmUEsvAYl6VpKZGiD8QQ1FaLfjlDGZKELATSlRbxL0x8MSvYReIJh/pc/HoR92IahKa Nlb3KyY5N6dwkXmbidULM9eDbjoU1+qTTqRvcJYCBDoiTZsVZX/ZGFC4bZ6weScf+cFd qWqw== 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=jLE+aas1zBHeNiW27ms2A+nAzVwCjfFwAHlElUgwHkU=; b=ktIUfp4aWagWEReOo6ZdCZfvo31Bl4Qye5RfQHeAzLU3edHLTalBfY0K4UyIIlBDGV 5K6yZyOCDp4KE6qJODKbQg0hg2nYkNsXd5Mc+BAlZHaKYlZpxkNDt7UmE6DaBwX4Uo36 pv32OCk3RHFM/f4gZ3J2I0IR+VYXhD6nD5RSILZBlP4gA0SYVD84C0/CFiBuWHLPjPvV 1yM/2bCa0gLXLTchVEi9ZdAjbBJ56280F/y1oL/Ag72dJQGV0032//e9LKzjrI6HwY2t Fw37igtH1q2IOrx1EefEkxJnf5fCv7g7B6jeAYlFC8wj+2eQlyz17X9H4rIUaAKgwjpW 8j5w== 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=jLE+aas1zBHeNiW27ms2A+nAzVwCjfFwAHlElUgwHkU=; b=TappmDhusA0bVmsneBWfgvQkNfuLbs6K8yEw/m2+Niacr0fPeu/net5G7Y5HMXNKdh B9sxePig2RYevNn0XTrSPB8LYaIGB/a1X3TQ1DNWtg9Z8lRWskDuXfci2ERPlVKugRCj ANUpsamS4Q7rZCZ5KJNlb5H3Z6mz8hmMCGpGk6qLcuEXQpdwO/2DH7YUFQudc3EL7lmc 6UC18BWkFNA8xNqox2fGaC8s8AM1OuXsmAo5NT7f9HPYfYLoJvvtze+waIGbnCbvd4xP +D26vRrb6GKmwqevm6IjGjaONYMrydch+fIkNpml0tUE78UjxlGu9/IAN1TVWlRhLQeD wUCQ== X-Gm-Message-State: AG10YOSeL0cI/HYgzhxAnUIkWMjKqI9Y/a399JjDpsePYVbonOPVaatIWtMx9nTriS6yhQ== X-Received: by 10.129.156.66 with SMTP id t63mr3189324ywg.38.1454528501788; Wed, 03 Feb 2016 11:41:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.32.194 with SMTP id g185ls606121iog.70.gmail; Wed, 03 Feb 2016 11:41:40 -0800 (PST) X-Received: by 10.50.41.5 with SMTP id b5mr245139igl.8.1454528500314; Wed, 03 Feb 2016 11:41:40 -0800 (PST) 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:24173 Archived-At: ------=_Part_7712_275069644.1454528499408 Content-Type: multipart/alternative; boundary="----=_Part_7713_2017654023.1454528499408" ------=_Part_7713_2017654023.1454528499408 Content-Type: text/plain; charset=UTF-8 On Wednesday, February 3, 2016 at 1:37:18 PM UTC-5, Matthew Woehlke wrote: > > On 2016-02-03 13:21, Thiago Macieira wrote: > > On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehlke > wrote: > >>> The reason for this is to make it easier to catch this undefined > behavior > >>> by requiring the program to fail fast. > >> > >> I previously proposed to make falling off a function be ill-formed: > >> > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/Yqjif > >> ANZtVsJ. I strongly encourage you to read that thread, as much of the > same > >> ground has been covered already. > > > > There's a big difference with the two proposals. To make it ill-formed, > you > > require the compiler to have absolutely no false positives or negatives. > > Calling std::terminate was also brought up in that thread. Also, those > issues can be addressed with standard 'not reachable' annotation, which > is valuable in its own right. > > > To make it call std::terminate(), we're only defining previously > > undefined behaviour and we don't need a 100% success rate. > > ...except now you're changing behavior if I *meant* to flow off the end > (e.g. because I'm doing something tricksy) to cause my program to fail > at runtime, Do people actually do that? More to the point, do we need to support people who are relying on undefined behavior? > rather than being able to detect at compile time that the > compiler wants to mangle my code. > > >> ...or you could just compile with -Werror=return-type. No diligence > >> required; your code won't build and you'll *have* to fix it. > > > > As Chris said in his OP, this does not catch everything due to false > positives > > and false negatives. > > Do you actually have an example of a false positive? I've *never* seen > one, and I'm curious what such an example looks like... > A false positive would be any time the compiler flags code that is actually functional, where control flow through the execution of the program doesn't reach the end of that function. And we know that it is *impossible* to do this correctly, because it's identical to the halting problem. So either you will get false negatives or false positives. Currently, C++ compilers err on the side of false negatives. And that is as it should be. > The compiler is allowed to give up if it can't prove one way or the > > other, so it often opts for assuming you know what you've done. > > If the compiler can't prove an issue, does it still insert a > std::terminate? Yes. It's functionally no different from sticking `std::terminate` at the end of any function that returns a value which doesn't end in a `return` statement. If the code never reaches it, no problem. If the compiler can prove that it never gets there, then it can easily insert nothing, based on the "as if" rule. > Why would it not also warn in such cases? Because "not proven" isn't the same thing as "*guilty*". Warning about functioning code is simply adding noise to the list of warnings, making it more likely the user will ignore genuinely useful ones. I would > really, really hope that the compiler has a warning for any time it > inserts a std::terminate for this reason... but in that case, the value > of requiring it to insert the std::terminate becomes dubious. > 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*. This approach (terminate at run-time rather than compile-time) feels > like a cop-out to me... and yes, "perfect is the enemy of good" and all > that, but here it feels too much like laziness. > Walking off the end of a function is only a runtime problem. So failing at compile time is the wrong way to handle it. Your way is not "perfect"; it's stopping people from writing perfectly functional code. -- --- 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/. ------=_Part_7713_2017654023.1454528499408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, February 3, 2016 at 1:37:18 PM UTC-5, Matthe= w Woehlke wrote:
On 2016-02-03 = 13:21, Thiago Macieira wrote:
> On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehl= ke wrote:
>>> The reason for this is to make it easier to catch this und= efined behavior
>>> by requiring the program to fail fast.
>>
>> I previously proposed to make falling off a function be ill-fo= rmed:
>> https://groups.google.com/a/isocpp.org/d/msg/std-= proposals/zu7IxDnnrNA/Yqjif
>> ANZtVsJ. I strongly encourage you to read that thread, as much= of the same
>> ground has been covered already.
>=20
> There's a big difference with the two proposals. To make it il= l-formed, you=20
> require the compiler to have absolutely no false positives or nega= tives.

Calling std::terminate was also brought up in that thread. Also, those
issues can be addressed with standard 'not reachable' annotatio= n, which
is valuable in its own right.

> To make it call std::terminate(), we're only defining previous= ly
> undefined behaviour and we don't need a 100% success rate.

...except now you're changing behavior if I *meant* to flow off the= end
(e.g. because I'm doing something tricksy) to cause my program to f= ail
at runtime,

Do people actually do that? More to th= e point, do we need to support people who are relying on undefined behavior= ?
=C2=A0
rather than b= eing able to detect at compile time that the
compiler wants to mangle my code.

>> ...or you could just compile with -Werror=3Dreturn-type. No di= ligence
>> required; your code won't build and you'll *have* to f= ix it.
>=20
> As Chris said in his OP, this does not catch everything due to fal= se positives=20
> and false negatives.

Do you actually have an example of a false positive? I've *never* s= een
one, and I'm curious what such an example looks like...

A false positive would be any time the compiler flags code th= at is actually functional, where control flow through the execution of the = program doesn't reach the end of that function. And we know that it is = impossible to do this correctly, because it's identical to the h= alting problem.

So either you will get false negatives or false posi= tives. Currently, C++ compilers err on the side of false negatives. And tha= t is as it should be.

> The compiler is allowed to give up if it can't prove one way or th= e
> other, so it often opts for assuming you know what you've done= ..

If the compiler can't prove an issue, does it still insert a
std::terminate?

Yes. It's functionally no diff= erent from sticking `std::terminate` at the end of any function that return= s a value which doesn't end in a `return` statement. If the code never = reaches it, no problem.

If the compiler can prove that it never gets= there, then it can easily insert nothing, based on the "as if" r= ule.
=C2=A0
Why would = it not also warn in such cases?

Because "not prov= en" isn't the same thing as "guilty". Warning abo= ut functioning code is simply adding noise to the list of warnings, making = it more likely the user will ignore genuinely useful ones.

I would
really, really hope that the compiler has a warning for any time it
inserts a std::terminate for this reason... but in that case, the value
of requiring it to insert the std::terminate becomes dubious.

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` h= as value. It causes my program to blow up when that runtime state is reache= d.

Your way prevents me from writing it even if I do it corre= ctly. The fact that I could have screwed it up doesn't mean I did.

This approach (terminate at run-time rather than compile-time) feels
like a cop-out to me... and yes, "perfect is the enemy of good&quo= t; and all
that, but here it feels too much like laziness.
Walking off the end of a function is only a runtime problem. So failing a= t compile time is the wrong way to handle it. Your way is not "perfect= "; it's stopping people from writing perfectly functional code.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_7713_2017654023.1454528499408-- ------=_Part_7712_275069644.1454528499408-- .