220 39407 <5d615d65-ca5e-4cbe-920b-59b47082b929@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Wed, 25 Jul 2018 11:27:13 -0700 (PDT) Lines: 246 Approved: news@gmane.org Message-ID: <5d615d65-ca5e-4cbe-920b-59b47082b929@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> <9ae0c0a2-2fde-4260-bae3-ba74623ec139@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_348_1830221235.1532543233759" X-Trace: blaine.gmane.org 1532543112 3169 195.159.176.226 (25 Jul 2018 18:25:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 18:25:12 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBAUC4PNAKGQEJ3BUAGQ@isocpp.org Wed Jul 25 20:25:07 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiOTB-0000eE-9Z for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 20:25:05 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id p127-v6sf4832513ywg.1 for ; Wed, 25 Jul 2018 11:27:16 -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=1LzQho3htuA2dvSe+LuKctzqsALPIGJB3Pcq/uvUAgI=; b=I8Fu5tqTKyzntIKAlCSwEYgbCq+oSTGgwaiTxyCaus/066tHkwVtK4AXANoMN8vSsm 0OaZGWt8QWzenP5XxmI+qtcFxy1Qof3MqILxqhPqXxjSytz8dNobKGQsTBDO/TzYGIrK tGrsqbTWBjA39gq+nsqcwkOk0OkUMLoPdvW7P6sm1qAV6s8o2CEdWV/oME7bFUCBIUJE 1O2Vn6v5+p0z/k/EhlGHlY5gFx1t9igU1r9lPV2QlV9ime0nTDgKYs1b1TGDWRhiUK2R xvcg027gD803x5gC9tCpupKAImxFEdXvLNzSeD+XFgbINruD1swzh+vUpZeLw5wIOcl6 dZtQ== 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=1LzQho3htuA2dvSe+LuKctzqsALPIGJB3Pcq/uvUAgI=; b=qfLZUWkkxwZew4AL7/70sz+tkhCg6wdnLfWa0Du7OnNsZJIATpvriaGtmE11XuzMRN RNHH9ny53MBpTzOKtekZpRMnwiKp0sqAi+wyFaLdae4VQHsgxXYnLQVbiytkZ6fhQHTC qfTrAObeEAc0/113Z2BmttzOqFG4NiLGczz2vZY7unf7OXHnnPACquTj6bsnAYsofAww TI7Nu7EH47oyqJjmZsqH8JW5BXFUbU9ill9zQNiMwLOM24I9WhTe+suSvmE7ftkmRDmh 81MKtGCgNYfQRYb6Nxc2ga575VYWHIXIU+MDfK3RvwJIzWLR8DHJm/gtLYLazGqnW/wR kFFA== 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=1LzQho3htuA2dvSe+LuKctzqsALPIGJB3Pcq/uvUAgI=; b=Ys5HNtY1ijJ+AgeoyUnoRFWBcUrsblBjWlQzs3QlbNAff/PHRd4Jg8o5eZE7VzgpIu YsHUET3dSMrPmTC477Jgc9FFfF3qNVcI0QIfQ/N3NZFkjJX+Uuc0PTUO7KqOTeYu97WF MXmWxxesgUvRXaXf0aylnnX5p1szM14MfSfV52uX234QWj2uephTpg0M3L7ER4KCIvEH QTZ+anoggzDZ8aJDBcn5hOJEFPRV/3oQ3k7ATA5eEmtIiiF607Y5w2yZLdn7HWRpCMFr 6h2gh53nYt18Fyw1yHyDpvoKwYNtGuJd3QhWL98jMelPGi8AGbNiivhsxinfD41EKct0 x0ug== X-Gm-Message-State: AOUpUlHsiiuQ8Sq1J7e/dDDQtkSsbub2jd5PGICjhZmHOE658rIfnfB4 oLUxpvHWmRPaiB9OS8sC4BbcvQ== X-Google-Smtp-Source: AAOMgpcDtuMsrYHYMc/C2NtXBUKcSX29BgbJ7iJn15DBLJIhW9s5aj09DPJ05gtiB47syTmJB1TSyw== X-Received: by 2002:a0d:d144:: with SMTP id t65-v6mr6474116ywd.197.1532543235738; Wed, 25 Jul 2018 11:27:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2548:: with SMTP id l69-v6ls3471137ybl.12.gmail; Wed, 25 Jul 2018 11:27:14 -0700 (PDT) X-Received: by 2002:a5b:60f:: with SMTP id d15-v6mr376000ybq.6.1532543234706; Wed, 25 Jul 2018 11:27:14 -0700 (PDT) In-Reply-To: <9ae0c0a2-2fde-4260-bae3-ba74623ec139@isocpp.org> X-Original-Sender: inkwizytoryankes@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:39407 Archived-At: ------=_Part_348_1830221235.1532543233759 Content-Type: multipart/alternative; boundary="----=_Part_349_1384241990.1532543233760" ------=_Part_349_1384241990.1532543233760 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 25, 2018 at 7:07:26 PM UTC+2, Nicol Bolas wrote: > > 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. > > Yes, and whole point is to expand things that are shared between C and C++ that more libs are compatible even if authors do not focus on this. > 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. > > Agree, this could this could work too. > 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 depend on exactly version will be added to C++, if we have only `std::error` then yes, if not and C++ support `throws{T}` then we could handle more types. But this will need some conversion because it would be very hard to have `_Fails(T)` and `throws{T}` for same type. Reason is different requirement for both versions. From previous discussion I could see this avoided by using different related types like `_Fails(T::exception_payload)` and `throws{T}`. If this new exception would be implemented in way I see then this will not be big problem but if another way will be choose then this indeed become problematic to easy share headers. > 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++. > Right -- 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/5d615d65-ca5e-4cbe-920b-59b47082b929%40isocpp.org. ------=_Part_349_1384241990.1532543233760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, July 25, 2018 at 7:07:26 PM UTC+2, N= icol Bolas wrote:
On Wednesday, July 25, 2018 at 12:43:54 PM UTC-4, Marcin Jaczewski wrot= e:
On Wednesday, Ju= ly 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 inte= ract with `constexpr`. Indeed, one of its biggest flaws is that it doesn= 9;t allow for inter-operation with C++ static exceptions at all, despite be= ing in part based on the same principle.
<= br>
My _Fails() proposal does however work in constexpr,

`_Fails()` is not valid C++, and `const= expr` 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 s= ell.

I appreciate you are proba= bly not up to date, as I have not issued a new draft of=C2=A0 D1095 which i= ncorporates 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(<expr>)` is a conditional<= /i> throws declaration, much like `noexcept(<expr>)`. P0709 makes tha= t abundantly clear.

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

= The only difference is auto-propagation, so a _Fails(T) if unhandled result= s in a failure to compile, whereas a throws(T) if unhandled propagates upwa= rds.

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 worke= d since 1998. C++11 did not incorporate C99 wholesale; it only took specifi= c things from it. Similarly, C++14/17/20 did not adopt C11 wholesale. The t= wo languages are diverging.

So why shou= ld we expect C++23 to adopt C22 in this way?

=
=C2=A0
To make easier to share code between? Im= age 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.
<= /div>

Define "using this library in C+= +23". Do you mean compiling it as C++? Or linking with it in C++? If i= t's compiling as C++, then that library's writer would still have t= o limit themselves to the subset of C22 that C++ supports.


Yes, and whole point is to expan= d things that are shared between C and C++ that more libs are compatible ev= en if authors do not focus on this.
=C2=A0
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 `ext= ern "C"` to be ABI-equivalent to a `_Fails(cxx_error)` or whateve= r. Yes, there would have to be two versions of the header to make that work= ..

However, if C++ consuming C heade= rs 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 t= hing, but that you can only fail with `cxx_error` as the type, and that suc= h 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.


Agree, this could this could work too.
=C2= =A0
The problem of course is that C users may not want to use our e= rror type. And if they don't, that limits interoperation drastically.


This depend o= n exactly version will be added to C++, if we have only `std::error` then y= es, if not and C++ support `throws{T}` then we could handle more types.
But this will need some conversion because it would be very hard to = have `_Fails(T)` and `throws{T}` for same type. Reason is different require= ment for both versions.
From previous discussion I could see this= avoided by using different related types like `_Fails(T::exception_payload= )` and `throws{T}`.
If this new exception would be implemented in= way I see then this will not be big problem but if another way will be cho= ose then this indeed become problematic to easy share headers.
=C2=A0
T= his is too other way around, it allow C++ to define headers that will be ea= sy consumable by C and other languages that will support C22 exceptions (th= is is major reason).

Such &= quot;C++ headers" would just be C22 headers, since they couldn't c= ontain any actual C++.

Righ= t

--
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/5d615d65-ca5e-4cbe-920b-59b47082b929= %40isocpp.org.
------=_Part_349_1384241990.1532543233760-- ------=_Part_348_1830221235.1532543233759-- .