[lib] Avoid 'shall' and 'should' in footnotes. #1986
Conversation
source/preprocessor.tex
Outdated
| The integer literal \tcode{\cppver}.\footnote{It is intended that future | ||
| The integer literal \tcode{\cppver}. | ||
| \begin{note} | ||
| It is intended that future | ||
| versions of this International Standard will | ||
| replace the value of this macro with a greater value. | ||
| Non-conforming compilers should use a value with at most |
There was a problem hiding this comment.
The Directives have a similar ban against "shall"/"should" in notes too...
There was a problem hiding this comment.
Yes, this is still not allowed by ISO. How about "Non-conforming compilers can use a value ..."?
Or we could drop that part of the note, since it no longer reflects reality. Before C++17 was close to publication some versions of GCC used 201500 to indicate "more than C++14 but less than C++1z", and at one point Clang used 201406.
There was a problem hiding this comment.
First, we can't really say something about non-conforming compilers; they're non-conforming anyway. Second, we now have feature-test macros.
So, the update removes the "should" sentence talking about non-conforming compilers.
tkoeppe
added
the
after-motions
|
@jwakely, @timsong-cpp: Could you please review this? |
| @@ -6818,7 +6818,7 @@ | |||
| elements of \tcode{v}.\footnote{This copy constructor creates | |||
| a distinct array rather than an alias. | |||
| Implementations in which arrays share storage are permitted, but they | |||
| shall implement a copy-on-reference mechanism to ensure that arrays are | |||
| would need to implement a copy-on-reference mechanism to ensure that arrays are | |||
There was a problem hiding this comment.
I'm going to merge as-is, but I wonder if we should just drop this -- in modern C++ this would also require taking a lock to provide thread-safety for const operations, which seems like a silly thing to bother describing as "permitted".
| \tcode{size_t} | ||
| (which is what Posix.2 calls | ||
| \tcode{ssize_t}).} | ||
| is used in most places where ISO C would use \tcode{size_t}.} |
There was a problem hiding this comment.
Sorry I've only noticed this now, but removing the mention of ssize_t seems unfortunate. Also, what remains of the footnote is a lie. We don't use streamsize for the size of an array new-expression or the size passed to operator new (corresponding to malloc in C), or the length passed to char_traits::compare (memcmp), or "most" other places. Maybe we should qualify this footnote to be specific to I/O in C, or just to places that actually use streamsize e.g.
Most places where
streamsizeis used would usesize_tin ISO C, orssize_tin POSIX APIs.
There was a problem hiding this comment.
Could you make a PR so we don't lose track of this? The suggestion sounds good.
Partially addresses #1414.