Is there any other concerns or suggestions ? Is it right direction from
your point of view ?

On Wed, 14 Oct 2020, 13:41 Denis Kotov, <redradist_at_[hidden]> wrote:

> >> Also this solution allows easier to adopt new syntax to existing code
>
> It will allow easier adopt Zero-overhead exception feature.
> This also could work with pointer and all other type, because internally
> code will be translate to:
>
> This code:
> ```cpp
> Subscription subscribe() throws SubscriptionError;
>
> Subscription subscribe() throws {
> ...
> throw SubscriptionError{"Error", Payload};
> ...
> }
> ```
> translates to:
> ```cpp
> struct SubscribeResult {
> Subscription res;
> SubscriptionError err;
> };
>
> SubscribeResult subscribe();
>
> SubscribeResult subscribe() {
> ...
> return SubscribeResult{ .err = SubscriptionError{"Error", Payload} };
> ...
> }
> ```
> or even more optimal:
> ```cpp
> union SubscribeResult {
> Subscription res;
> SubscriptionError err;
> };
>
> SubscribeResult subscribe();
>
> SubscribeResult subscribe() {
> ...
> return SubscribeResult{ .err = SubscriptionError{"Error", Payload} };
> ...
> }
> ```
>
> I think it could depend on compiler implementation, but instead of raw
> integer we could have any object with the same effect Zero-overhead ;)
>
> On Wed, 14 Oct 2020 at 13:35, Denis Kotov <redradist_at_[hidden]> wrote:
>
>> This can work if definitions if will be added this following syntax:
>>
>> ```cpp
>> Subscription subscribe() throws SubscriptionError;
>>
>> Subscription subscribe() throws {
>> ...
>> throw SubscriptionError{"Error", Payload};
>> ...
>> }
>> ```
>>
>> This syntax solves the issue when you need to add some data to exceptions.
>> Also this solution allows easier to adopt new syntax to existing code
>>
>> On Tue, 13 Oct 2020 at 03:17, Jason McKesson via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> On Mon, Oct 12, 2020 at 5:01 PM Denis Kotov via Std-Discussion
>>> <std-discussion_at_[hidden]> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I would like to discuss Zero-Overhead proposal, I would like if Herb
>>> Sutter will participate
>>> >
>>> > >>
>>> > I was so exited when I first saw your video with Zero-Overhead
>>> exception proposal that this proposal stuck in my head and I thought about
>>> it while to while ...
>>> >
>>> > Today I decided that to wrote some my thought about it:
>>> > I little bit disagree the we need to return std::error instead of
>>> exception because it is possible to make Zero-Overhead exceptions without
>>> changing the way of checking exceptions
>>> >
>>> > How can we achieve it ... ?
>>> > Easy, we just need to implicitly to add to signature of the function
>>> the list of exceptions that it throw ...
>>> > Wow, wow, wow ... I hear from you, but it was the previous solution
>>> with dynamic exception ...
>>> > Not exactly, consider the example:
>>> > void func throws {
>>> > throw WeirdException("Some Weird Exception");
>>> > }
>>> >
>>> > it will translates at compilation time to this:
>>> > void func throws(WeirdException)
>>> >
>>> > It will be done by compiler without user interaction ... It will allow
>>> on caller side (for compiler) to know exactly which exceptions function
>>> throw, and compiler would be able to generate code something like in the
>>> example of GodBolt (see below)
>>>
>>> First, this only works under the same circumstances as return type
>>> auto-deduction. So if the definition needs to be elsewhere for any
>>> reason, it just doesn't work. Also, it can't work through function
>>> pointers or any other runtime indirect calling mechanism
>>> (`std::function`, etc), unlike proper static exceptions.
>>>
>>> Second, it's unclear what problem this solves. `std::error` can carry
>>> any exception as it currently stands. So you can already throw
>>> `WeirdException`. And you can catch the exception too, even though you
>>> have to catch `std::error` and extract the proper exception object
>>> from it.
>>>
>>> The only thing this might do is add a bit of syntactic sugar at the
>>> catch site. And that sugar doesn't require annotating the function (by
>>> the compiler or anyone else).
>>>
>>> Also, what happens if you have two functions which throw different
>>> exceptions, and you just let them throw those exceptions to the
>>> caller? What type does the compiler add to your function?
>>> --
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>
>>
>>
>> --
>>
>> *Best RegardsDenis Kotov*
>>
>
>
> --
>
> *Best RegardsDenis Kotov*
>