Date: Thu, 3 Oct 2019 16:46:32 -0400
On Tue, Oct 1, 2019 at 4:59 PM sotrdg sotrdg via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
https://bitbucket.org/ejsvifq_mabmip/proposal/raw/a88e370134e31d5b6f084d686ba829b7f4627b2c/2215.pdf
Interesting. I'm generally sympathetic to your concerns about Herbceptions;
I think they don't solve most of the problems they set out to. However,
your paper
- is in drastic need of proofreading,
- reads as unnecessarily aggrieved,
- makes several wrong-sounding claims without citing evidence, and
- 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 <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`?
> 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
std-proposals_at_[hidden]> wrote:
>
>
https://bitbucket.org/ejsvifq_mabmip/proposal/raw/a88e370134e31d5b6f084d686ba829b7f4627b2c/2215.pdf
Interesting. I'm generally sympathetic to your concerns about Herbceptions;
I think they don't solve most of the problems they set out to. However,
your paper
- is in drastic need of proofreading,
- reads as unnecessarily aggrieved,
- makes several wrong-sounding claims without citing evidence, and
- 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 <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`?
> 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
Received on 2019-10-03 15:48:57