220 39387 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Tue, 24 Jul 2018 18:24:43 -0700 (PDT) Lines: 154 Approved: news@gmane.org Message-ID: References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <1c229827-6d5d-45bd-8766-c3af818b2b0b@isocpp.org> <4ac80882-16fc-4ab4-9a12-64da1ef0e974@isocpp.org> <8866881c-ef1d-4c37-9242-5b1d3327c288@isocpp.org> <363df3db-b747-449f-b95d-81d15b6c3842@isocpp.org> <76fcc1f3-6d58-409c-824e-47af1c49d3ec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9366_1083856855.1532481884106" X-Trace: blaine.gmane.org 1532481760 13119 195.159.176.226 (25 Jul 2018 01:22:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 01:22:40 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBXNC37NAKGQELOLXVTQ@isocpp.org Wed Jul 25 03:22:35 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fi8Vf-0003JE-Fu for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 03:22:35 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id l1-v6sf3362670ywm.11 for ; Tue, 24 Jul 2018 18:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=014II3SFD6EgpW8o0rD7gpRklNYcPn3129LcDAS90vw=; b=EyFA0gaR28l1/IUvD0ED3xkUHlZL4rT2YSrjB9k25sN30tss0R9nCdGSy4+XMDOxgE pRUKt7HpPfvcctPqNQEe7NTBSWGFLx9j4ICa9VIXEbt0Oq4xsiBTm7Au1J3VEIca33X+ AziiqR7KdveixFQ22+ocRFO8r5sBg9xlRFjPffRDwINIBE/TzA7GOKz22276co/NVerD bnExPVnLmNuJ7+3pNQ9PcGIWrlPBXfjUU/rVrsIBXvs1VbCCChX//TfTdykavqfA8kWU qdC9gQgkArFuPNZQXCkO4AOu0a07hfPBLMUNfne14LFlY4MeJnQQ920iZ6K6pJFKvVo/ qWKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=014II3SFD6EgpW8o0rD7gpRklNYcPn3129LcDAS90vw=; b=lFAukYd4RPy3sNeV5GhJFI19zVa40VH/UEqARL4pTWOfFXdejf8wK4S6qswQo2fj7E iQnuTFwEv0sQu2uPee1gpwLKYiN77lWxYJ9bnEv7cP3h5t/H62BtCivIiHuvM9B/gkB7 PuGOqK0q2QUPg8+PcdtXVydY2xcKPkF4PlEohrNbETYfx/oWr3XThZwqJ2Zu1s9eEiXD 1upf3GHsjyPx4h3gp6xYbDtAh/CEhgTmq0BYdZ0ZK8/p8c6GsQzmO7VZkj4z+UXb7Iep 5Nyfu+WDK+QSOY0g7AbCarl4Yr4c44Z124uxTgUePj38o2lEu919b3Oy9GTt2DYpS1pI yt8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=014II3SFD6EgpW8o0rD7gpRklNYcPn3129LcDAS90vw=; b=lU6PGbYboOdsc4rfMbmm2nCbb1CW17zRnfhXFfvZDytlm/USYmGPnS7xdh4ppPUjfz /TaZkhXuNbgSMUmYI3LYsMuV90D3j1HpBP9ie7tqDE7+DUDFhkvxyaTH8f73i5kCyjCc Nf1/vnA+XqYMJ7VX6T8fDYEWtkST7wOzDR+BSDjZMFw7SliXiwcqO+6ZaQ8XOhpbhF1B uYn8jtSYcBk71atjN4DGBr+O5YuS5GFvNyks9NA6hcqWRpQhFPzARFxvCqyDXo4HdSQh T5HFW+47zkckvu1OTtQrNaQ62TNGGt5JhZGgUn1hR67VpHpekmcuF0j8T0knwKp4GY87 qxXw== X-Gm-Message-State: AOUpUlGT1+/GEDwExz1ISjHtfeueFvAPfpWfPQk6TQ6PyLiIYfXSWVjp 5a1nZ3qlXRLq4J4vT28S6G+b4Q== X-Google-Smtp-Source: AAOMgpd+gcFwqMePMUMthmPhQ1Q7+aF2fF58tyDWLu47gI2YXT8TNRpvHDMM6K19OuUgC2oz/SAiWQ== X-Received: by 2002:a81:2f05:: with SMTP id v5-v6mr5750865ywv.202.1532481885994; Tue, 24 Jul 2018 18:24:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a703:: with SMTP id e3-v6ls1609423ywh.37.gmail; Tue, 24 Jul 2018 18:24:44 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr363252ywc.7.1532481884587; Tue, 24 Jul 2018 18:24:44 -0700 (PDT) In-Reply-To: <76fcc1f3-6d58-409c-824e-47af1c49d3ec@isocpp.org> 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:39387 Archived-At: ------=_Part_9366_1083856855.1532481884106 Content-Type: multipart/alternative; boundary="----=_Part_9367_1957304967.1532481884106" ------=_Part_9367_1957304967.1532481884106 Content-Type: text/plain; charset="UTF-8" On Tuesday, July 24, 2018 at 6:55:55 PM UTC-4, Marcin Jaczewski wrote: > > On Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nicol Bolas wrote: >> >> On Tuesday, July 24, 2018 at 1:52:21 PM UTC-4, Niall Douglas wrote: >>> >>> Well, that leaves me with egg on my face. The proposal certainly makes >>>>> more sense given what you've said. On a similar note, then, what would this >>>>> do to our constexpr? >>>>> >>>> >>>> It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of >>>> its biggest flaws is that it doesn't allow for inter-operation with C++ >>>> static exceptions at all, despite being in part based on the same principle. >>>> >>> >>> My _Fails() proposal does however work in constexpr, >>> >> >> `_Fails()` is not valid C++, and `constexpr` is not valid C. How can they >> work with one another? Unless you're proposing to add `_Fails()` to C++, >> which I think would be a rather hard sell. >> > > Why not? > Because P0709 is superior in pretty much every way. From the fixed, simple, and highly flexible error type to making error handling control flow distinct from regular code flow, and with plenty of points of extension besides (such as my suggestion for allowing `try` to unpack ValueOrError types into exceptions). I just don't see any reason to use the C mechanism. Doubly so because it is only compatible if you choose to make it compatible (by using `_Fails` with the `std::error`-equivalent object). So why have an option that people shouldn't be using? C++ inhered multiple things from C, this could be another one. > And C++ has *not* inherited multiple other things from C; this could be another one. The `_Fails()` mechanism is a perfectly fine C-ism. But it is not a C++ solution to the problem, and we should not encourage it by canonizing it for our language. They may share the underlying ABI, similar substructure for communicating between functions. And there could even be some declaration in the C++ standard which says that an `extern "C"` function declared with `throws` shall be equivalent in some way to a C function with `_Fails(cxx_error)` or whatever. But having `_Fails()` be legal C++? No. The point of giving C `_Fails()` from our perspective is so that C++ static exceptions can at least pass *through* C APIs. If Niall define this functionality in compatible way for C++ then we need > only add one paragraph that "behavior of C exceptions from C2x work same > way in C++2y" and another one how glue both. I would even go further and > build C++ exception on top of C as syntax sugar but this probably is not > direction that Niall is going. > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a32c119b-f891-4bf1-b130-e1815954b86e%40isocpp.org. ------=_Part_9367_1957304967.1532481884106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, July 24, 2018 at 6:55:55 PM UTC-4, Marcin Jacz= ewski wrote:
O= n Tuesday, July 24, 2018 at 8:36:02 PM UTC+2, Nicol Bolas wrote:
On Tuesday, July 24, 2018 at = 1:52:21 PM UTC-4, Niall Douglas wrote:
Well, that leaves me with egg on my face. The proposal certainly makes m= ore sense given what you've said. On a similar note, then, what would t= his do to our constexpr?

It'= ;s a C proposal; it doesn't interact with `constexpr`. Indeed, one of i= ts biggest flaws is that it doesn't allow for inter-operation with C++ = static exceptions at all, despite being in part based on the same principle= ..

My _Fails() proposal does= however work in constexpr,

`_F= ails()` is not valid C++, and `constexpr` is not valid C. How can they work= with one another? Unless you're proposing to add `_Fails()` to C++, wh= ich I think would be a rather hard sell.

<= /div>
Why not?

Because P070= 9 is superior in pretty much every way. From the fixed, simple, and highly = flexible error type to making error handling control flow distinct from reg= ular code flow, and with plenty of points of extension besides (such as my = suggestion for allowing `try` to unpack ValueOrError types into exceptions)= ..

I just don't see any reason to use the C mec= hanism. Doubly so because it is only compatible if you choose to make it co= mpatible (by using `_Fails` with the `std::error`-equivalent object). So wh= y have an option that people shouldn't be using?

C++ in= hered multiple things from C, this could be another one.

And C++ has not inherited multiple other t= hings from C; this could be another one. The `_Fails()` mechanism is a perf= ectly fine C-ism. But it is not a C++ solution to the problem, and we shoul= d not encourage it by canonizing it for our language.

<= div>They may share the underlying ABI, similar substructure for communicati= ng between functions. And there could even be some declaration in the C++ s= tandard which says that an `extern "C"` function declared with `t= hrows` shall be equivalent in some way to a C function with `_Fails(cxx_err= or)` or whatever.

But having `_Fails()` be legal C= ++? No. The point of giving C `_Fails()` from our perspective is so that C+= + static exceptions can at least pass through C APIs.
=
If Niall define this functionality in compatible way for C++ then we need= only add one paragraph that "behavior of C exceptions from C2x work s= ame way in C++2y" and another one how glue both. I would even go furth= er and build C++ exception on top of C as syntax sugar but this probably is= not direction that Niall is going.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/a32c119b-f891-4bf1-b130-e1815954b86e= %40isocpp.org.
------=_Part_9367_1957304967.1532481884106-- ------=_Part_9366_1083856855.1532481884106-- .