-
Notifications
You must be signed in to change notification settings - Fork 771
[expr.unary.noexcept] Replace informative wording #6539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
source/expressions.tex
Outdated
The \keyword{noexcept} operator yields \keyword{true} | ||
unless the full-expression of the operand | ||
is potentially-throwing\iref{except.spec}. | ||
The operand of the \keyword{noexcept} operator | ||
is an unevaluated operand\iref{term.unevaluated.operand}. | ||
\begin{bnf} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is some room for improvement in this subclause, but talking about "the operand" in detail before we've even introduced the grammar seems unhelpful.
My suggestion:
- grammar first
- then talk about the operand
- then talk about the result
- then have the note about constant expression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented most of what you've suggested, but I don't understand what you mean by "note about constant expression". Neither the old wording nor the new wording talks about constant expressions.
Wouldn't adding a note be a topic for another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"[Note 1 : A noexcept-expression is an integral constant expression (7.7). — end note]"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, I wasn't looking at the second paragraph. I've moved it up now.
99fce49
to
8f480b2
Compare
Sorry, but that's not exactly what I had in mind. Since the change is a little larger, I've created CWG2792 to have CWG review the change. See there for my suggestion; feel free to continue to discuss here. |
Context and Problem with the Current Wording
I was briefly under the impression that
a + b
can throw for twoint
sa
andb
, because signed integer overflow is UB, and UB can result in throwing exceptions, and maybe thenoexcept
operator needs to consider that.Paragraph 1 in its current form says:
An unsuspecting reader like me might assume that this includes exceptions thrown as the result of UB. However, this isn't actually possible, and this wording is purely informative. Paragraph 3 contains the actual normative wording, explaining that the
noexcept
operator checks whether an expression is potentially-throwing.Suggested Solution
This PR moves the actual normative wording from p3 up into p1 to avoid any future confusion. The informative wording is removed.