[std] Replace other forbidden words in notes and examples

Author: jensmaurer

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};
@@ -1025,7 +1025,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.

source/compatibility.tex

@@ -1350,7 +1350,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 may 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
@@ -1476,7 +1476,7 @@
 \rationale
 Better interaction with other language features.
 \effect
-Valid \CppXIV{} code that uses inheriting constructors may not be valid
+Valid \CppXIV{} code that uses inheriting constructors can be invalid
 or may 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
@@ -2157,7 +2157,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{}.
@@ -2236,7 +2236,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.
@@ -2343,7 +2343,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}
 
@@ -2941,7 +2941,7 @@
 
 \diffref{dcl.fct} [see \ref{expr.sizeof}]
 \change
-In \Cpp{}, types may not be defined in return or parameter types.
+In \Cpp{}, it is not allowed to define types in return or parameter types.
 In C, these type definitions are allowed.
 
 Example:
@@ -3256,7 +3256,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.
 
 Example:
 \begin{codeblock}

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 expected to be more specialized\iref{temp.func.order} to be selected.
   \end{note}
 
 \item

source/containers.tex

@@ -22334,7 +22334,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()]}

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}
 

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

source/expressions.tex

@@ -1443,7 +1443,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}

source/iterators.tex

@@ -1213,7 +1213,7 @@
 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
+overload is viable, program-defined overloads are expected to be more
 specialized\iref{temp.func.order} to be selected.
 \end{note}
 

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,7 +6226,7 @@
 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
+An \tcode{unsynchronized_pool_resource} class is not permitted to be accessed
 from multiple threads simultaneously
 and thus avoids the cost of synchronization entirely
 in single-threaded applications.

source/support.tex

@@ -6182,7 +6182,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

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

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 that 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 supported only if aligned to \tcode{2*alignof(double)}.
 \end{note}
 \end{itemdescr}
 

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}