I, personally, think that a lot of people are "fighting a strawman", trying
to address wrong questions.

The main problem with exceptions (and therefore, the reason why they are
banned) is not overhead, but their "implicit-ness".
People want to understand what is going on (I mean, is it possible to have
an error in this particular function or not, and which error exactly)
without having to recall each line in the entire codebase, but rather by
looking on the signature of a function.
The property of locality if very important - that is exactly what OOP is
about - being able to reason about code, without having to remember distant
part of codebase is crucial. Herb's exceptions do not do much in this
regard...

I have already posted here my take on the topic, but in case you
missed it, here
it is
<https://www.reddit.com/r/cpp/comments/cliw5j/should_not_exceptions_be_finally_deprecated/>
.

On Sat, 5 Oct 2019 at 06:39, Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> “Section 3 seems out-of-place. You're switching from a conservative
>> critique of Herb's existing proposal, to an even wilder proposal of your
>> own? Flying cars will never work, but let me tell you my ideas on personal
>> jetpacks?”
>>
>>
>> What is the point of criticizing other people’s works without providing
>> solution? Complaining for no reason?
>>
>
> Well, you should be able to deal with the merits (or lack thereof) of
> Herb's proposal completely orthogonally to your own "solution."
> Your paper has two different things going on:
> (1) a critique of Herb's proposal, which I think makes some valid points
> and some invalid points;
> (2) a promotion of your own proposal [Java-style checked exceptions +
> noexcept(auto)], which I think is much more flawed than Herb's.
> Right now you're tying those two orthogonal issues together. In my
> opinion, the naivete of (2) reduces your credibility in re (1). Someone
> else might disagree with (1), and then view (2) as irrelevant.
>
>
>
>> “Your `dynamic_exception` type sounds exactly isomorphic to C++11 `
>> std::exception_ptr
>> <https://en.cppreference.com/w/cpp/error/exception_ptr>`. Have you seen
>> `exception_ptr` before? After looking at `exception_ptr`, what differences
>> do you see between `exception_ptr` and your ideas about
>> `dynamic_exception`?”
>>
>>
>>
>> I agree dynamic_exception is a fault. I have a new solution to that which
>> is throws exception should not be allowed to be bound to a pointer or
>> virtual function, just like constexpr. If people want that, they need to
>> use current exception. I will provide a revised version of my proposal in
>> the next few days.
>>
>
> Please, take a look at std::exception_ptr on cppreference. See if it does
> what you're looking for.
>
>
> In general, variant-based exception works and it is the only real
>> zero-overhead exception proposal.
>>
>
> When you use phrases like "real zero-overhead", it makes me think that
> you're exaggerating or naïve.
> C++ exceptions are "zero-overhead" in the sense that you don't pay for
> test-and-branch at each level of a successful call stack; but they are
> "non-zero overhead" in many other ways. Your proposed exception mechanism,
> like Herbceptions, is "zero-overhead" in the sense that you don't need any
> auxiliary data tables to tell you how to perform stack unwinding; but it is
> "non-zero overhead" in the sense that it inserts test-and-branch
> instructions at each level of the call stack, slowing down your code's
> happy path.
>
>
> - "Sutter thinks exceptions and RTTI are the only two violators of the
>> zero-overhead principle."
>> That is true. Herb Sutter did say that in his video and his paper.
>>
>> “RTTI is the other C++ language feature that violates the zero-overhead
>> principle. [...]"
>>
>
> Good. Cite this in your paper.
> Don't just claim or assert it; provide *evidence* for your claim. If that
> means linking to YouTube, or to another committee paper, do so!
>
>
> - "Introducing a new keyword is a problem." Introducing a new contextual
>> keyword `throws`, in the same place as `override` and `final`, is actually
>> not troubling at all. By pretending that it is a problem, you cast doubt on
>> the rest of your arguments.
>>
>>
>>
>> False. As Bjrane demoed in the previous cppcons Even introducing nullptr
>> would cause problem since it is possible some people are using nullptr as
>> variable name. Same thing with why coroutine keywords are called co_yield,
>> co_return instad of yield or resume
>>
>
> `override`, `final`, and Herb's `throws` keyword are not a problem for
> C++'s grammar in the way that e.g. `yield` is.
> For more information on the grammar of contextual keywords, see N3163
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3163.pdf>.
>
>
> - "The prototype has not completed yet." (by which you mean "there is no
>> implementation of std::error available") Quite possibly true, but I would
>> like to see a link to a GitHub or something. I bet someone has at least
>> tried to implement it, right? No?
>>
>>
>>
>> 14ned’s implementation is horrible and not freestanding.
>>
>
> So, someone *has* tried to implement it? I'd like to see your paper
> offer a link to that implementation.
> It would also be interesting to see *why* you think that implementation
> is "horrible."
> Maybe you could come up with a code snippet (on Compiler Explorer, for
> example) that shows a significant difference in performance between that
> implementation and the optimal one.
>
> - "A lot of middle school algorithm competition like NOIP is banning
>> containers or not enabling optimization toggle." Citation wanted.
>>
>>
>>
>> Evidence?
>>
>
> Yes. Again, in the form of a link, in the paper.
> http://www.noi.cn/newsview.html?id=67&hash=2DA1FD&type=6 counts as
> evidence. Put it in the paper.
> (Although, uncharitably, I wonder why these rules are 10 years old and
> exist only in Chinese. The rules for the 2019 International Olympiad in
> Informatics are here <https://ioi2019.az/en-content-26.html>, and they
> don't mention any banned headers.)
>
>
> - "C++ code still cannot run on a lot of platforms with no ABIs of dynamic
>> exceptions, web assembly, for example." Is this saying that C++ compilers
>> targeting WebAssembly can't use try/throw/catch? Citation wanted.
>>
>>
>>
>> It just aborts. Why do you not even watch Cppcon 2019?
>>
>> https://youtu.be/5N4b-rU-OAA?t=4690
>>
>
> I've watched it now, thanks! I had not watched that link before you sent
> it because I'm not a mind-reader. Put it in your paper.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Dmitry
*Sent from gmail*