Replace "shall not throw" with "does not throw" when it describes library behavior #3229
Conversation
Quuxplusone
force-pushed
the
shall-does
branch
from
9038bcc
to
78f9930
Compare
jensmaurer
added
the
needs rebase
|
Please rebase and fix the conflicts, then force-push. |
|
The existing wording also applies to program-defined specializations of |
Quuxplusone
force-pushed
the
shall-does
branch
from
78f9930
to
db3adc3
Compare
Quuxplusone
force-pushed
the
shall-does
branch
2 times, most recently
from
dd2172f
to
8af12ba
Compare
jensmaurer
added
changes requested
|
@Quuxplusone, there are a few minor changes requested. Please apply them, rebase, and force-push. Thank you. |
…ry behavior. In these places we aren't saying "it's UB if X happens"; we're literally specifying the behavior of a library function as "X does not happen, we promise." Jonathan Wakely points out that there is still room for the user to cause UB by specializing `pair`, `duration`, `function`, etc. such that their specializations do X. In that case, the UB happens due to [namespace.std] p2, which requires that "the [program-defined] specialization meets the standard library requirements for the original template."
Quuxplusone
force-pushed
the
shall-does
branch
from
8af12ba
to
5088f9e
Compare
jensmaurer
removed
the
changes requested
| The defaulted move and copy constructor, respectively, of \tcode{pair} shall | ||
| be a constexpr function if and only if all required element-wise | ||
| The defaulted move and copy constructor, respectively, of \tcode{pair} | ||
| is a constexpr function if and only if all required element-wise |
There was a problem hiding this comment.
Pre-existing: s/is a constexpr function/are constexpr functions/
There was a problem hiding this comment.
Right now the grammar is: "The X and Y, respectively, is Z if A and B, respectively, satisfies some condition."
I guess you're suggesting: "The X and Y, respectively, are Z if A and B, respectively, satisfy some condition."
Another alternative: "The X or Y, respectively, is Z if A or B, respectively, satisfies some condition."
FWIW, I think this grammar is just too far from proper to have a "right" answer, but my guess was that the singular is more correct — because it's possible for X to be Z independently of Y. Each of X and Y is Z independently of the other.
There was a problem hiding this comment.
FWIW, I think this grammar is just too far from proper to have a "right" answer
Amen to that: this sentence is a painfully awkward demonstration of the lengths we'll go to in order to avoid repetition. We should probably simply strike it, since
- "shall be a constexpr function" doesn't mean what the Library thinks it means,
- the core language tells us when defaulted constructors are
constexpr, there's no need to repeat it here, and - [functions.within.classes] says we "do not describe copy/move constructors, assignment operators, or (non-virtual) destructors with the same apparent semantics as those that can be generated by default".
but that may be a bit of a stretch for an editorial change.
Feel free to ignore this comment, accept it, and/or file an LWG issue to strike the paragraph altogether.
There was a problem hiding this comment.
This is awful. But it's pre-existing, so I'm not blocking this pull request on it. If someone wants to take some additional action here, please do! (I think I'll change the "and"s to something else as a short-term "fix".)
There was a problem hiding this comment.
Also, hold on just a minute, this is saying that the defaulted move constructor is constexpr if all copies are valid and the defaulted copy constructor is constexpr if all moves are valid. What the ...?
There was a problem hiding this comment.
If someone wants to take some additional action here
Ideally, additional action involving cleansing flame.
source/utilities.tex
Outdated
| @@ -15659,7 +15659,7 @@ | |||
| reference to an object and a member function pointer. \end{note} | |||
|
|
|||
| \pnum | |||
| \throws Shall not throw exceptions when \tcode{f} is a function pointer | |||
| \throws Does not throw exceptions when \tcode{f} is a function pointer | |||
There was a problem hiding this comment.
Pre-existing: the inconsistency between this wording and the wording for the copy constructor is unfortunate. I suggest Does not throw exceptions if \tcode{f} is a function pointer or an instance of a specialization of \tcode{reference_wrapper}.
In these places we aren't saying "it's UB if it throws"; we're literally specifying the behavior of a library function as "it does not throw, we promise."