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*