Fix forbidden words in notes and examples #7039
Conversation
| @@ -6030,7 +6030,7 @@ | |||
| struct X { X(A*); }; | |||
|
|
|||
| struct E : C, D, X { | |||
| E() : D(this), // undefined behavior: upcast from \tcode{E*} to \tcode{A*} might use path \tcode{E*} $\rightarrow$ \tcode{D*} $\rightarrow$ \tcode{A*} | |||
| E() : D(this), // undefined behavior: upcast from \tcode{E*} to \tcode{A*} can use path \tcode{E*} $\rightarrow$ \tcode{D*} $\rightarrow$ \tcode{A*} | |||
There was a problem hiding this comment.
Would this one be better as "could"?
There was a problem hiding this comment.
ISO doesn't like "could" in notes and examples, I think.
There was a problem hiding this comment.
It's actually a bit more subtle than that: The verbal forms for provisions are strictly controlled. But if we're not expressing a provision, then there's in principle no restriction. What ISO/CS is worried about then is that one might mistakenly misunderstand something to be a provision (even though it's not meant to be one), and they then recommend rephrasing it so that such a misunderstanding can't happen.
We can belabor this separately for the WD, but for the IS I'd be OK to accept a somewhat crude replacement.
| @@ -6702,7 +6702,7 @@ | |||
| the expression resulting from the interpretation of \tcode{x @ y} | |||
| using the selected rewritten candidate\iref{over.match.oper} | |||
| does not result in a usable candidate | |||
| (for example, that expression might be \tcode{(x <=> y) @ 0}), or | |||
| (for example, that expression can be \tcode{(x <=> y) @ 0}), or | |||
There was a problem hiding this comment.
I'm not really sure I correctly understand what this \item is even saying, so I don't think the parenthetical example helps me.
Would this be clearer?
| (for example, that expression can be \tcode{(x <=> y) @ 0}), or | |
| (for example, when the resulting expression is \tcode{(x <=> y) @ 0}), or |
There was a problem hiding this comment.
No, that's not what we want to say. Your rewrite sounds like it's an example for "does not result in a usable candidate". The original phrasing just wants to give an example for the "expression resulting from the interpretation ... using the rewritten candidate". The rewritten candidate might be <=>.
Within the confines of what we can use, "can" is as good as we get here, I think.
source/support.tex
Outdated
| @@ -546,7 +546,7 @@ | |||
| after inclusion of any member of the set of library headers | |||
| indicated in the corresponding comment in this synopsis. | |||
| \begin{note} | |||
| Future revisions of \Cpp{} might replace | |||
| Future revisions of \Cpp{} can replace | |||
There was a problem hiding this comment.
"It is not guaranteed that future revisions of C++ will not replace the values ..."?
There was a problem hiding this comment.
No. We want to say / handwave that the values will never become smaller. Your rephrasing loses that.
|
Maybe I should have said that this is for the IS only, and I have no trouble killing English grammar or C++ semantics there. |
|
Understood, but I'd prefer not to get defects reported because the IS says things are impossible when it intends to say they might not happen. Oh well, they're mostly just notes anyway. |
|
This is great, thank you! I will pull these two commits into the IS only. As before, I'd like to consider for each change whether it's actually an improvement, and if so, we'll also apply it to the WD. (But this can happen asynchronously.) |
Fixes ISO/CS comment (C++23 proof)
Fixes ISO/CS comment (C++23 proof)
wg21bot
added
the
needs rebase
Fixes ISO/CS comment (C++23 proof)
Carefully select each hunk when / if applying to the Working Draft.