[std] Remove problematic phrases from notes #6758
Conversation
tkoeppe
force-pushed
the
required
branch
4 times, most recently
from
88312a6 to
e9c3253
Compare
Only specific phrases involving the word "required" are problematic, namely when they appear to establish a normative requirement. They have been reworded, often by replacing "is required" with "needs", sometimes with slightly larger edits.
tkoeppe
changed the title
| The generic format is required to ensure lexicographical | ||
| comparison works correctly. | ||
| It is possible that the use of the generic format is needed | ||
| to ensure correct lexicographical comparison. |
There was a problem hiding this comment.
Sigh. This would be so much easier to read as "The use of the generic format may be needed to ensure ..." if that wasn't a forbidden word.
This is so that notes do not (inappropriately) state requirements or permissions.
|
Uh, I'm a bit late to the game, it seems. Anyway, the changes look good to me. (I dimly remember that we've excised "need" in a prior iteration, because that was considered a bad word at some point, but if that's a good word now --- fine.) |
|
Thanks, Jens! I think "need" does not appear as an official equivalent phrase in https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor078. For that matter, I also don't see "could" and "might" being generally forbidden; they're merely not allowed for provisions. I'm not sure if ISO is really consistent in what they're asking for... I do still want to compose a general guidance document for the wording groups. I think what we can agree on so far is that a) provisions have to use the explicitly describled verbal forms, and b) notes must not contain requirements, recommendations, permissions, or instructions. It's true that "might" should not be used for permission (instead of "may"), but that doesn't seem to ban "might" outright. I think the argument (back from the C++20 cycle) was similar to the argument against "cannot" we have now: that it is not immediately clear that the word isn't accidentally trying to be a permission or requirement. And that's perhaps not a bad point. Anyway, we're just left with all the "cannot"s now. |
|
Do you ... want to do something about the "cannot"s? Some of them were recently introduced as workarounds for other forbidden words. |
| @@ -1558,7 +1558,7 @@ | |||
| \begin{codeblock} | |||
| friend class T; | |||
| \end{codeblock} | |||
| is ill-formed. However, the similar declaration \tcode{friend T;} is allowed\iref{class.friend}. | |||
| is ill-formed. However, the similar declaration \tcode{friend T;} is well-formed.\iref{class.friend}. | |||
There was a problem hiding this comment.
@tkoeppe You introduced an extra period . here — the one after the \iref should stay but the new one before the \iref should be deleted again.
Only specific phrases involving the word "required" are problematic, namely when they appear to establish a normative requirement. They have been reworded, often by replacing "is required" with "needs", sometimes with slightly larger edits.
Also reword "necessary", "permitted", "allowed" in notes, so that they do not (inappropriately) state requirements or
permissions.
On request of ISO.