- veers off into a poorly-thought-out counter-proposal in the last 4 pages.
For "proofreading": would you consider publishing the LaTeX source code and accepting pull requests? At least you should change all instances of "fragilize" and "fragilized" to the English words "fragment" and "fragmented".
For "tone": pull requests might also help with this, but basically I think what'll help the most is to organize and focus your arguments to avoid getting distracted by minor points (such as the `isspace` thing). I would even recommend that you cut the last 4 pages — or else cut the first 7 pages! One or the other is not relevant to your theme.
For "citations needed":
- "Sutter thinks exceptions and RTTI are the only two violators of the zero-overhead principle."
- "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.
- "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?
- "A lot of middle school algorithm competition like NOIP is banning containers or not enabling optimization toggle." Citation wanted.
- "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 is not possible for std::error and ntstatus having a one-to-one mapping." My impression is that you're wrong about this. My understanding of the current vague ideas around std::error is that it would be like std::error_code — you could totally have a std::error in the NTSTATUS domain ("category"), whose payload ("code") is an arbitrary 32-bit integer.
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?
Your `dynamic_exception` type sounds exactly isomorphic to C++11 `
std::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`?
> This paper will revise the old deprecating exception specification with new meaning.
What "new meaning" are you assigning to throw-specifications? On first reading, it looks like you mean to give them exactly the same meaning that they had in C++03. If programmers didn't use throw-specifications in C++03 — if programmers often dislike checked exceptions even in Java — why would programmers want to use them in future-C++?
Section 3.10, "auto noexcept", is the feature often known as "noexcept(auto)".
Please read
https://quuxplusone.github.io/blog/2018/06/12/attribute-noexcept-verify/
HTH,
Arthur