220 39328 <7e8f93d6-7dd8-422f-a13f-b63b43d772ec@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Tue, 24 Jul 2018 01:20:24 -0700 (PDT) Lines: 117 Approved: news@gmane.org Message-ID: <7e8f93d6-7dd8-422f-a13f-b63b43d772ec@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <1c229827-6d5d-45bd-8766-c3af818b2b0b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8818_1047639448.1532420424347" X-Trace: blaine.gmane.org 1532420299 3620 195.159.176.226 (24 Jul 2018 08:18:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2018 08:18:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBSOC3PNAKGQEPMAMG7Q@isocpp.org Tue Jul 24 10:18:15 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhsWN-0000q0-5D for gclcip-std-proposals@m.gmane.org; Tue, 24 Jul 2018 10:18:15 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id r144-v6sf1782810ywg.9 for ; Tue, 24 Jul 2018 01:20:26 -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=VXxwZ0FlPRWfavOQPkSH0VKRQh8/RcJG0LY3wkWofbo=; b=xUN6c4VLA0yp1uTPcOtv2W0ycArFg6vceYVajWCxbouWVTozowNNRfQkrFokb/jzDl YuVbXJYcM6pb/3gd22uxI6/Cc1BnhZ52oCk2fHDwdikaE4BNNRVcKFhRMJvDR5bsvZPG NZUrw2m7kKcczUwNFt6qJBr9+A2y6WaDMs8cooWBzSyELlV7eTyYvdcRwy669AhncuI6 X7Hyc/K2jt5XbVsBTw2/PDRnWwx4UDd7keIBd4EHC6diYlptAoY3gcE5CHhmsZ5NgeyO u0u37nWEsXX3zpydIhwQSNJhGA4TG1xf6ensctmuApc9jEsgldcJ+4vk9k/67JDzSnyk CQkg== 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=VXxwZ0FlPRWfavOQPkSH0VKRQh8/RcJG0LY3wkWofbo=; b=Nft1WaFrI4xLD3BwNwIptDREDRJq7Rt4YHVLvVCiwcBdUsCK3TvZWQE3JvxNjoy/Re gtTECdvXp0MPv/WwI6FBZ28G7iMZnMeV+6Xxeu4LrTCqm5+j203xtPy33dRWcv6EYuYz G85rpSnWiHxD7Ke0qGsOIbt4cnbcx5xUyRnPItCgpxMhSVJGEdKwIXKcBn+MwVUMRcqV 7N89h11z9lNJFywAEsWtGCJeWD/+/MuZgfO7fW4pTzwfeJalo+SsOjxuBoL2wtwLyvM/ TaAopoDiZAGdsI2NkEF/Cwyk4l7PGAMNfDJdibvLdtvQoMHxdpdOAWpt61sDYDtQ0dWN H+Ew== 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=VXxwZ0FlPRWfavOQPkSH0VKRQh8/RcJG0LY3wkWofbo=; b=SC5Y4Vi1wlD9Q8yiC84H0/mKxjJiwOCgJLciAapPoSBEgBuoE6wYbNn3yljpcvnVBI vbkFgfGmG3ugrGNh47UquvOVCSXD2Y5XBI8jsyWGaHBTMR87qIkATe0Kh49ct6LpHjAh A/Kjbq6WTAs6JtG8xg5qF12ALz35TUt3uPkd7WbqSCU/nZABqnOrPX3kThI28/BpBNHT 6RyzY+zAd2j7ddkQae9BplGJmH3pJN3989AmYg9lr0X4opeJEXW0hh+2s//JOLS5omkH ZHDXEkRH7oAVlbh8TNVq3UByw6Mern08IV+5nsJxWcgFq5KV4vKIEZS98GQ0hEweRhFK nbCQ== X-Gm-Message-State: AOUpUlHWxFZ0tBKusaDzKD9Ow8245fwpi/c1yzjc6/obflJrELjmDUU7 IZhZRbhpy9V4Cpy/k9DVqbCy8g== X-Google-Smtp-Source: AAOMgpe18Z7OUn7sl8FnVwdAW6cF2Hp3SHbK2sZjnrwH6HPFNRPc3wceJC1SMexGv4ziJ2iU6q4kdA== X-Received: by 2002:a81:b1ca:: with SMTP id p193-v6mr4627791ywh.104.1532420425973; Tue, 24 Jul 2018 01:20:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:d512:: with SMTP id x18-v6ls347663ywd.28.gmail; Tue, 24 Jul 2018 01:20:25 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr298292ywc.7.1532420424942; Tue, 24 Jul 2018 01:20:24 -0700 (PDT) In-Reply-To: X-Original-Sender: nialldouglas14@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:39328 Archived-At: ------=_Part_8818_1047639448.1532420424347 Content-Type: multipart/alternative; boundary="----=_Part_8819_211700596.1532420424347" ------=_Part_8819_211700596.1532420424347 Content-Type: text/plain; charset="UTF-8" On Monday, July 23, 2018 at 11:19:28 PM UTC+1, Bengt Gustafsson wrote: > > Would it be unthinkable for C to implement this limited form of > throw/catch system in full? After all almost all C compilers are also C++ > compilers so the implementation job is probably negative (you don't have to > differentiate between languages in the compiler code). > The next draft of my D1095 proposal is a one-to-one mapping into C of P0709 deterministic exceptions + P1028 std::error. The mechanism I think has consensus on WG14. The choice of standard error object (std::error) is disliked by a significant minority in C because you must fall back onto either a library or macro based API to construct and inspect such objects. Now, me personally, I find that acceptable, though obviously laborious to work with. Some on WG14 want the compiler to hide more boilerplate. Hence the counterproposal. The next draft of D1095 I think won't mention any standard error object. That can be another paper for WG14, and we in C++ can simply provide a C macro API for P1028 like Boost.Outcome does. > > I guess the main problem would be the keywords as such, but maybe the > __throw/__except that is already used (and thereby reserved) in MSVC can be > used at least. > > Those keywords will always implement type based C++ exception handling. You must remember that those are not going anywhere in future C++. We'll have two exception throwing mechanisms, value based and type based. This is unavoidable if you wish to preserve backwards binary compatibility. I also suspect that std::uncaught_exceptions() and possibly std::exception_ptr is unimplementable in deterministic exceptions, so code relying on them would break if we simply switched all exceptions to the new mechanism. (Just to be clear, I think a compiler flag should be available which turns on all-deterministic exceptions, with legacy exceptions emulated, but with some functions like the above no longer compiling in some circumstances. But I don't think it should be default) Niall -- 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/7e8f93d6-7dd8-422f-a13f-b63b43d772ec%40isocpp.org. ------=_Part_8819_211700596.1532420424347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, July 23, 2018 at 11:19:28 PM UTC+1, Bengt Gusta= fsson wrote:
W= ould it be unthinkable for C to implement this limited form of throw/catch = system in full? After all almost all C compilers are also C++ compilers so = the implementation job is probably negative (you don't have to differen= tiate between languages in the compiler code).

<= /div>
The next draft of my D1095 proposal is a one-to-one mapping into = C of P0709 deterministic exceptions + P1028 std::error. The mechanism I thi= nk has consensus on WG14. The choice of standard error object (std::error) = is disliked by a significant minority in C because you must fall back onto = either a library or macro based API to construct and inspect such objects.<= /div>

Now, me personally, I find that acceptable, though= obviously laborious to work with. Some on WG14 want the compiler to hide m= ore boilerplate. Hence the counterproposal.

The ne= xt draft of D1095 I think won't mention any standard error object. That= can be another paper for WG14, and we in C++ can simply provide a C macro = API for P1028 like Boost.Outcome does.
=C2=A0

I guess= the main problem would be the keywords as such, but maybe the __throw/__ex= cept that is already used (and thereby reserved) in MSVC can be used at lea= st.=C2=A0


Those = keywords will always implement type based C++ exception handling. You must = remember that those are not going anywhere in future C++. We'll have tw= o exception throwing mechanisms, value based and type based. This is unavoi= dable if you wish to preserve backwards binary compatibility. I also suspec= t that std::uncaught_exceptions() and possibly std::exception_ptr is unimpl= ementable in deterministic exceptions, so code relying on them would break = if we simply switched all exceptions to the new mechanism.

(Just to be clear, I think a compiler flag should be available whi= ch turns on all-deterministic exceptions, with legacy exceptions emulated, = but with some functions like the above no longer compiling in some circumst= ances. But I don't think it should be default)

Niall

--
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/7e8f93d6-7dd8-422f-a13f-b63b43d772ec= %40isocpp.org.
------=_Part_8819_211700596.1532420424347-- ------=_Part_8818_1047639448.1532420424347-- .