[std] Replace other forbidden words in notes and examples

jensmaurer · tkoeppe · commit 1274d64301c1 · 2024-07-10T14:03:00.000+01:00
Fixes ISO/CS comment (C++23 proof)
diff --git a/source/classes.tex b/source/classes.tex
@@ -65,7 +65,7 @@
 \grammarterm{class-head} omits the
 \grammarterm{class-head-name} defines an \defnadj{unnamed}{class}.
 \begin{note}
-An unnamed class thus can't
+An unnamed class thus cannot
 be \tcode{final}.
 \end{note}
 Otherwise, the \grammarterm{class-name} is an \grammarterm{identifier};
@@ -1026,7 +1026,7 @@
 Programs shall not define implicitly-declared special member functions.
 
 \pnum
-Programs may explicitly refer to implicitly-declared special member functions.
+Programs can explicitly refer to implicitly-declared special member functions.
 \begin{example}
 A program may explicitly call or form a pointer to member
 to an implicitly-declared special member function.
diff --git a/source/compatibility.tex b/source/compatibility.tex
@@ -1391,7 +1391,7 @@
 \rationale
 Prevents accidental uses of trigraphs in non-raw string literals and comments.
 \effect
-Valid \CppXIV{} code that uses trigraphs may not be valid or may have different
+Valid \CppXIV{} code that uses trigraphs can be invalid or have different
 semantics in this revision of \Cpp{}. Implementations may choose to
 translate trigraphs as specified in \CppXIV{} if they appear outside of a raw
 string literal, as part of the \impldef{mapping input source file characters
@@ -1521,8 +1521,8 @@
 \rationale
 Better interaction with other language features.
 \effect
-Valid \CppXIV{} code that uses inheriting constructors may not be valid
-or may have different semantics. A \grammarterm{using-declaration}
+Valid \CppXIV{} code that uses inheriting constructors can be invalid
+or have different semantics. A \grammarterm{using-declaration}
 that names a constructor now makes the corresponding base class constructors
 visible to initializations of the derived class
 rather than declaring additional derived class constructors.
@@ -2218,7 +2218,7 @@
 \rationale
 Avoid hard to diagnose or non-portable constructs.
 \effect
-Names of attribute identifiers may not be used as macro names. Valid \CppIII{}
+It is not allowed to use names of attribute identifiers as macro names. Valid \CppIII{}
 code that defines \tcode{override}, \tcode{final},
 \tcode{carries_dependency}, or \tcode{noreturn} as macros is invalid in this
 revision of \Cpp{}.
@@ -2297,7 +2297,7 @@
 Lack of specification of complexity of \tcode{size()} resulted in
 divergent implementations with inconsistent performance characteristics.
 \effect
-Some container implementations that conform to \CppIII{} may not conform to the
+It is possible that some container implementations that conform to \CppIII{} do not conform to the
 specified \tcode{size()} requirements in this revision of \Cpp{}. Adjusting
 containers such as \tcode{std::list} to the stricter requirements may require
 incompatible changes.
@@ -2404,7 +2404,7 @@
 \effect
 Valid \CppIII{} code that uses implementation-specific knowledge about the
 binary representation of the required template specializations of
-\tcode{std::complex} may not be compatible with this revision of \Cpp{}.
+\tcode{std::complex} can be incompatible with this revision of \Cpp{}.
 
 \rSec2[diff.cpp03.locale]{\ref{localization}: localization library}
 
@@ -2414,7 +2414,7 @@
 \rationale
 Required by new feature.
 \effect
-Valid \CppIII{} code may have different behavior in this revision of \Cpp{}.
+Valid \CppIII{} code can have different behavior in this revision of \Cpp{}.
 
 \rSec2[diff.cpp03.input.output]{\ref{input.output}: input/output library}
 
@@ -3020,7 +3020,7 @@
 
 \diffref{dcl.fct} [see \ref{expr.sizeof}]
 \change
-In \Cpp{}, types may not be defined in return or parameter types.
+In \Cpp{}, defining types in return or parameter types is not allowed.
 In C, these type definitions are allowed.
 
 \begin{example}
@@ -3347,7 +3347,7 @@
 
 \diffref{class.member.lookup}
 \change
-In \Cpp{}, a \grammarterm{typedef-name} may not be redeclared in a class definition after being used in that definition.
+In \Cpp{}, it is not allowed to redeclare a \grammarterm{typedef-name} in a class definition after being used in that definition.
 
 \begin{example}
 \begin{codeblock}
diff --git a/source/concepts.tex b/source/concepts.tex
@@ -623,7 +623,7 @@
   \begin{note}
   This precludes calling unconstrained program-defined overloads of
   \tcode{swap}. When the deleted overload is viable, program-defined overloads
-  need to be more specialized\iref{temp.func.order} to be selected.
+  are only selected if they are more specialized\iref{temp.func.order}.
   \end{note}
 
 \item
diff --git a/source/containers.tex b/source/containers.tex
@@ -22314,7 +22314,7 @@
 \pnum
 \begin{note}
 Concrete accessor policies can impose preconditions for their \tcode{access} function.
-However, they can not.
+However, it is possible that they do not.
 For example, an accessor where
 \tcode{p} is \tcode{span<A::element_type, dynamic_extent>} and
 \tcode{access(p, i)} returns \tcode{p[i \% p.size()]}
diff --git a/source/declarations.tex b/source/declarations.tex
@@ -6291,7 +6291,7 @@
 \end{itemize}
 
 \begin{note}
-As indicated above, such conversions are not allowed at the top level in
+As indicated above, such conversions are not possible at the top level in
 list-initializations.
 \end{note}
 \begin{example}
@@ -9377,7 +9377,7 @@
   [[maybe_unused]] x:
 }
 \end{codeblock}
-Implementations should not warn that \tcode{b} or \tcode{x} is unused,
+Implementations are discouraged from warning that \tcode{b} or \tcode{x} is unused,
 whether or not \tcode{NDEBUG} is defined.
 \end{example}
 
diff --git a/source/exceptions.tex b/source/exceptions.tex
@@ -987,8 +987,9 @@
 A defaulted declaration does not require the
 exception specification of a base member function to be evaluated
 until the implicit exception specification of the derived
-function is needed, but an explicit \grammarterm{noexcept-specifier} needs
-the implicit exception specification to compare against.
+function is needed, but an explicit \grammarterm{noexcept-specifier}
+compares against
+the implicit exception specification.
 \end{note}
 \end{itemize}
 The exception specification of a defaulted
diff --git a/source/expressions.tex b/source/expressions.tex
@@ -1445,7 +1445,7 @@
 \end{codeblock}
 In each case, the constraints of \tcode{f} are not satisfied.
 In the declaration of \tcode{p2},
-those constraints need to be satisfied
+those constraints are expected to be satisfied
 even though
 \tcode{f} is an unevaluated operand\iref{term.unevaluated.operand}.
 \end{example}
diff --git a/source/iterators.tex b/source/iterators.tex
@@ -1213,8 +1213,8 @@
 the program is ill-formed, no diagnostic required.
 \begin{note}
 This precludes calling unconstrained \tcode{std::iter_swap}. When the deleted
-overload is viable, program-defined overloads need to be more
-specialized\iref{temp.func.order} to be selected.
+overload is viable, program-defined overloads are only selected
+if they are more specialized\iref{temp.func.order}.
 \end{note}
 
 \item Otherwise, if the types of \tcode{E1} and \tcode{E2} each model
diff --git a/source/memory.tex b/source/memory.tex
@@ -2115,7 +2115,7 @@
 Given an allocator type \tcode{X}\iref{allocator.requirements.general} and
 letting \tcode{A} be a synonym for \tcode{allocator_traits<X>}, the types \tcode{A::pointer},
 \tcode{A::const_pointer}, \tcode{A::void_pointer}, and \tcode{A::const_void_pointer}
-may be used as \tcode{unique_ptr<T, D>::pointer}.
+can be used as \tcode{unique_ptr<T, D>::pointer}.
 \end{example}
 
 \rSec4[unique.ptr.single.ctor]{Constructors}
@@ -4852,14 +4852,9 @@
 \pnum
 \tcode{operator()(x, y)} returns \tcode{x.owner_before(y)}.
 \begin{note}
-Note that
-\begin{itemize}
-\item \tcode{operator()} defines a strict weak ordering as defined in~\ref{alg.sorting};
-
-\item
+\tcode{operator()} defines a strict weak ordering as defined in~\ref{alg.sorting}.
 \tcode{!operator()(a, b) \&\& !operator()(b, a)} is \tcode{true}
 if and only if \tcode{a.owner_equal(b)} is \tcode{true}.
-\end{itemize}
 \end{note}
 
 \rSec3[util.smartptr.owner.hash]{Struct \tcode{owner_hash}}
@@ -6231,10 +6226,9 @@
 A \tcode{synchronized_pool_resource} may be accessed from multiple threads
 without external synchronization
 and may have thread-specific pools to reduce synchronization costs.
-An \tcode{unsynchronized_pool_resource} class may not be accessed
-from multiple threads simultaneously
-and thus avoids the cost of synchronization entirely
-in single-threaded applications.
+Using an \tcode{unsynchronized_pool_resource} from multiple threads
+results in potentially concurrent conflicting accesses\iref{intro.races},
+but use within a single thread avoids the need for any synchronization.
 
 \indexlibraryglobal{pool_options}%
 \indexlibraryglobal{synchronized_pool_resource}%
diff --git a/source/support.tex b/source/support.tex
@@ -6187,7 +6187,7 @@
 \begin{example}
 The header \libheader{cstdlib} assuredly
 provides its declarations and definitions within the namespace
-\tcode{std}. It may also provide these names within the
+\tcode{std}. It can also provide these names within the
 global namespace.
 The header \libheader{stdlib.h}
 assuredly provides the same declarations and definitions within
diff --git a/source/templates.tex b/source/templates.tex
@@ -6358,7 +6358,7 @@
 
 \pnum
 \begin{note}
-An explicit instantiation of a constrained template needs
+An explicit instantiation of a constrained template is expected
 to satisfy that template's associated constraints\iref{temp.constr.decl}.
 The satisfaction of constraints is determined
 % FIXME: What is a "template name"? Does this mean "simple-template-id"?
@@ -6681,7 +6681,7 @@
 
 \pnum
 \begin{note}
-An explicit specialization of a constrained template needs
+An explicit specialization of a constrained template is expected
 to satisfy that template's associated constraints\iref{temp.constr.decl}.
 The satisfaction of constraints is determined
 when forming the template name of an explicit specialization
diff --git a/source/threads.tex b/source/threads.tex
@@ -57,11 +57,11 @@
 in~\ref{res.on.exception.handling}.
 
 \begin{example}
-Consider a function in this Clause that is specified to throw exceptions of type
+If a function in this Clause is specified to throw exceptions of type
 \tcode{system_error} and specifies error conditions that include
 \tcode{operation_not_permitted} for a thread that does not have the privilege to
-perform the operation. Assume that, during the execution of this function, an \tcode{errno}
-of \tcode{EPERM} is reported by a POSIX API call used by the implementation. Since POSIX
+perform the operation, and if during the execution of this function, an \tcode{errno}
+of \tcode{EPERM} is reported by a POSIX API call used by the implementation, since POSIX
 specifies an \tcode{errno} of \tcode{EPERM} when ``the caller does not have the privilege
 to perform the operation'', the implementation maps \tcode{EPERM} to an
 \tcode{error_condition} of \tcode{operation_not_permitted}\iref{syserr} and an exception
@@ -2516,8 +2516,9 @@
 \item \tcode{memory_order::consume}: a load operation performs a consume operation on the
 affected memory location.
 \begin{note}
-Prefer \tcode{memory_order::acquire}, which provides stronger guarantees
-than \tcode{memory_order::consume}. Implementations have found it infeasible
+\tcode{memory_order::acquire}, which provides stronger guarantees
+than \tcode{memory_order::consume}, is preferred.
+Implementations have found it infeasible
 to provide performance better than that of \tcode{memory_order::acquire}.
 Specification revisions are under consideration.
 \end{note}
@@ -2606,7 +2607,7 @@
 
 \pnum
 \begin{note}
-We do not require that $S$ be consistent with
+It is not necessary for $S$ to be consistent with
 ``happens before''\iref{intro.races}.
 This allows more efficient implementation
 of \tcode{memory_order::acquire} and \tcode{memory_order::release}
@@ -2908,14 +2909,14 @@
 
 \pnum
 \begin{note}
-Hardware could require an object
+Hardware can require an object
 referenced by an \tcode{atomic_ref}
 to have stricter alignment\iref{basic.align}
 than other objects of type \tcode{T}.
 Further, whether operations on an \tcode{atomic_ref}
-are lock-free could depend on the alignment of the referenced object.
+are lock-free can depend on the alignment of the referenced object.
 For example, lock-free operations on \tcode{std::complex<double>}
-could be supported only if aligned to \tcode{2*alignof(double)}.
+can be restricted to alignment to \tcode{2*alignof(double)}.
 \end{note}
 \end{itemdescr}
 
diff --git a/source/utilities.tex b/source/utilities.tex
@@ -1359,7 +1359,7 @@
 \begin{codeblock}
 return pair<int, double>(5, 3.1415926);     // explicit types
 \end{codeblock}
-a \Cpp{} program may contain:
+a \Cpp{} program can contain:
 \begin{codeblock}
 return make_pair(5, 3.1415926);             // types are deduced
 \end{codeblock}
