220 39402 <9ae0c0a2-2fde-4260-bae3-ba74623ec139@isocpp.org> 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: Wed, 25 Jul 2018 10:07:25 -0700 (PDT) Lines: 192 Approved: news@gmane.org Message-ID: <9ae0c0a2-2fde-4260-bae3-ba74623ec139@isocpp.org> 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> <61682de8-3bf2-42d4-ae19-fcf3bd1d93a0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_631_879644784.1532538445856" X-Trace: blaine.gmane.org 1532538321 23188 195.159.176.226 (25 Jul 2018 17:05:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 17:05:21 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTW44LNAKGQE2KN3ONQ@isocpp.org Wed Jul 25 19:05:17 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiNDw-0005w0-QE for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 19:05:17 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id 189-v6sf4237625ybz.11 for ; Wed, 25 Jul 2018 10:07:28 -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=60saVWWPHGBxMUVfTCrO3R7kvM5nbiiC1Qbt8iSNm0k=; b=Tlogc+7/pIgWze+pfuZYT9zHb+v2JxT5J4ReGsyPEyQI8Nw2dUAn6mFG3N0x2aIBK5 uzWd4W+3tOE3l4xm4gF1d2rOkJeggaT6f0KZinKPRcSaYrtAjqXe6/YOuLj6JIwK8NMm wF6PdLdqGvxP49+DEud2FYB8aflKvQ5/vLqZMtmmOCiVx5GIbZnoJe7b6Fz0Y/0/jDFL zOmoqGMD6AzGHGdQdoGaUrWhgkcNNQnnR3b4dSuYu5IWub/QJFDjwkATkeVWX2fhOzk0 kXmsa0S/xmtJoW9Hz3dMpwt7A7KlBDwMRnhy7SpkjEWuASkjtcqwzd6N3dBvD3J7KXf/ 3Ouw== 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=60saVWWPHGBxMUVfTCrO3R7kvM5nbiiC1Qbt8iSNm0k=; b=NG23fP0/FrHpg8E3uCSSVZHEnuaz7T+RRrAjBf0RCPpLNDy+L9koYCIokkii+ZhQsf Yv/Se1hoIIofuJ//fWMCuX+rQ/dwng/+uvkIFEBf5FOxkhXpBsN5OzJh6zLZnhMB1Kia 2hWq9++ycKUYg3azqRgNrqtwZKZ27kHSnbGJPViashngLsCoV+O/wLVolJjgoMuFfw5Z a2FIDpEZ7lHL8+hG2s/MYYbdAw+RG5mM0JEpFhsCKPVcUhrdj75kN8SBvgJI5WbTUAxd cRiiIqYe/1VDcIwIQdRKgYNOEGe3Sr7FWt0uk7JIh1PMrQfIb3Anhx5sXbruW6/2IUDw RyXA== 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=60saVWWPHGBxMUVfTCrO3R7kvM5nbiiC1Qbt8iSNm0k=; b=nVKeLmGxrdrS3Tl2ZKPbPammq9A4IcGUCTy82O+P2l2xG82I4Sm1io8WT25MFC8xES 2LTZaW8Sui1pU2DjJscBcP1xXQrl/Jz1ZKfb99tx0ASNdbLKazmEGAW7aTC8vVoiBpLv jTF5flzr32aXRvgc/oJJQEfbjt3OvpYDGBc2RRPj5bMVqXc9q+Y35Nd4pj48PqPVYvzP E7tHA9xZPqOWiVD07gzXRr1CyEOQio0ntIZnXPA3LP/ZREy1lTHsFTypyIGfzkE+YDKd q7lN3Mv3zQ1t6XVfFM9Sw3En+wf4lbow6dVQQQdZVcovtVfouQEQ0eO+TQSvWv0ZOuBr oDfA== X-Gm-Message-State: AOUpUlFWzjL5gRh4CveZJznRkTQi4Ndhvbz6rMRZbQVuFpXZShDv/gS3 qDoZT2Mp2Y5ErfkcUiqCKbBq1w== X-Google-Smtp-Source: AAOMgpcF+SFn1yisDbMAZhkXJQzbbpRu0CrWuzquVp4sPPeyUHtTPwmE45VN/zyM46Cf4EUGu0j72Q== X-Received: by 2002:a0d:c8c5:: with SMTP id k188-v6mr3157615ywd.130.1532538447508; Wed, 25 Jul 2018 10:07:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:e6d7:: with SMTP id p206-v6ls2244936ywe.12.gmail; Wed, 25 Jul 2018 10:07:26 -0700 (PDT) X-Received: by 2002:a0d:de01:: with SMTP id h1-v6mr399297ywe.3.1532538446436; Wed, 25 Jul 2018 10:07:26 -0700 (PDT) In-Reply-To: <61682de8-3bf2-42d4-ae19-fcf3bd1d93a0@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:39402 Archived-At: ------=_Part_631_879644784.1532538445856 Content-Type: multipart/alternative; boundary="----=_Part_632_1086212527.1532538445856" ------=_Part_632_1086212527.1532538445856 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin Jaczewski wrote: > > On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote: >> >> On Wednesday, July 25, 2018 at 4:14:33 AM UTC-4, Niall Douglas wrote: >>> >>> >>>>>> 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. >>>> >>> >>> I appreciate you are probably not up to date, as I have not issued a new >>> draft of D1095 which incorporates the substantial feedback I received from >>> WG14. And I have only very briefly summarised what will go into that draft >>> on std-proposals and /r/cpp/. >>> >>> But in short, C22 _Fails(T) maps directly onto C++ 23 throws(T). >>> >> >> Pedantic note: `throws(T)` doesn't exist. `throws()` is a >> *conditional* throws declaration, much like `noexcept()`. P0709 >> makes that abundantly clear. >> >> What you're looking for is `throws{T}`. Which P0709 treats as an >> extension, not a required part of the proposal. So there's no guarantee it >> will make it into any hypothetical C++23. >> >> The only difference is auto-propagation, so a _Fails(T) if unhandled >>> results in a failure to compile, whereas a throws(T) if unhandled >>> propagates upwards. >>> >>> This is what WG14 asked for. As C++ 23 would surely be incorporating C22 >>> into itself, whatever goes into C also goes in C++. >>> >> >> That's not how C++ has worked since 1998. C++11 did not incorporate C99 >> wholesale; it only took specific things from it. Similarly, C++14/17/20 did >> not adopt C11 wholesale. The two languages are *diverging*. >> >> So why should we expect C++23 to adopt C22 in this way? >> >> > To make easier to share code between? Image big C22 library that use this > new calling convention in headers, if we accept this part of C22 using this > library in C++23 will be trivial. > Define "using this library in C++23". Do you mean compiling it as C++? Or linking with it in C++? If it's compiling as C++, then that library's writer would still have to limit themselves to the subset of C22 that C++ supports. If you're talking about ABI interop, we don't need C++ to be able to read C22 to have that. ABIs can allow a C++ `throws` function that is declared `extern "C"` to be ABI-equivalent to a `_Fails(cxx_error)` or whatever. Yes, there would have to be two versions of the header to make that work. However, if C++ consuming C headers directly is an important thing, then C++ would still not have to include the entire mechanism. We would simply declare that `_Fails()` is a legal thing, but that you can only fail with `cxx_error` as the type, and that such a function's declaration is exactly equivalent to a function declared with `throws`. And that's it. C uses its mechanism on its side, and C++ uses its mechanism on its side. The problem of course is that C users may not want to use our error type. And if they don't, that limits interoperation drastically. This is too other way around, it allow C++ to define headers that will be > easy consumable by C and other languages that will support C22 exceptions > (this is major reason). > Such "C++ headers" would just be C22 headers, since they couldn't contain any actual C++. -- 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/9ae0c0a2-2fde-4260-bae3-ba74623ec139%40isocpp.org. ------=_Part_632_1086212527.1532538445856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin J= aczewski wrote:
On Wednesday, July 25, 2018 at 5:24:19 PM UTC+2, Nicol Bolas wrote:
On Wednesday, July 25, 2= 018 at 4:14:33 AM UTC-4, Niall Douglas wrote:

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

My _Fails() proposal does however work in c= onstexpr,

`_Fails()` is not val= id 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.

I apprec= iate you are probably not up to date, as I have not issued a new draft of= =C2=A0 D1095 which incorporates the substantial feedback I received from WG= 14. And I have only very briefly summarised what will go into that draft on= std-proposals and /r/cpp/.

But in short, C22 _Fai= ls(T) maps directly onto C++ 23 throws(T).

Pedantic note: `throws(T)` doesn't exist. `throws(<expr>)` = is a conditional throws declaration, much like `noexcept(<expr>= ;)`. P0709 makes that abundantly clear.

What you&#= 39;re looking for is `throws{T}`. Which P0709 treats as an extension, not a= required part of the proposal. So there's no guarantee it will make it= into any hypothetical C++23.

The only difference is auto-propagation, so a _Fails(T)= if unhandled results in a failure to compile, whereas a throws(T) if unhan= dled propagates upwards.

This is what WG14 asked f= or. As C++ 23 would surely be incorporating C22 into itself, whatever goes = into C also goes in C++.

That's n= ot how C++ has worked since 1998. C++11 did not incorporate C99 wholesale; = it only took specific things from it. Similarly, C++14/17/20 did not adopt = C11 wholesale. The two languages are diverging.

So why should we expect C++23 to adopt C22 in this way?
<= div>
=C2=A0
To make easier to sh= are code between? Image big C22 library that use this new calling conventio= n in headers, if we accept this part of C22 using this library in C++23 wil= l be trivial.

Define "usin= g this library in C++23". Do you mean compiling it as C++? Or linking = with it in C++? If it's compiling as C++, then that library's write= r would still have to limit themselves to the subset of C22 that C++ suppor= ts.

If you're talking about ABI interop, we do= n't need C++ to be able to read C22 to have that. ABIs can allow a C++ = `throws` function that is declared `extern "C"` to be ABI-equival= ent to a `_Fails(cxx_error)` or whatever. Yes, there would have to be two v= ersions of the header to make that work.

However, if C++ consuming C headers directly is an important thing, t= hen C++ would still not have to include the entire mechanism. We would simp= ly declare that `_Fails()` is a legal thing, but that you can only fail wit= h `cxx_error` as the type, and that such a function's declaration is ex= actly equivalent to a function declared with `throws`. And that's it. C= uses its mechanism on its side, and C++ uses its mechanism on its side.

The problem of course is that C users may not want t= o use our error type. And if they don't, that limits interoperation dra= stically.

This is too other way around, it allow C++ to d= efine headers that will be easy consumable by C and other languages that wi= ll support C22 exceptions (this is major reason).

Such "C++ headers" would just be C22 heade= rs, since they couldn't contain any actual C++.

--
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/9ae0c0a2-2fde-4260-bae3-ba74623ec139= %40isocpp.org.
------=_Part_632_1086212527.1532538445856-- ------=_Part_631_879644784.1532538445856-- .