Fix modal verbs

source/algorithms.tex

@@ -203,10 +203,11 @@
 \pnum
 \begin{note}
 Unless otherwise specified, algorithms that take function objects as arguments
-are permitted to copy those function objects freely.
-Programmers for whom object identity is important should consider
-using a wrapper class that points to a noncopied implementation object
-such as \tcode{reference_wrapper<T>}\iref{refwrap}, or some equivalent solution.
+can copy those function objects freely.
+If object identity is important,
+a wrapper class that points to a noncopied implementation object
+such as \tcode{reference_wrapper<T>}\iref{refwrap}, or some equivalent solution,
+can be used.
 \end{note}
 
 \pnum
@@ -261,8 +262,8 @@
 The number and order of deducible template parameters for algorithm declarations
 are unspecified, except where explicitly stated otherwise.
 \begin{note}
-Consequently, the algorithms may not
-be called with explicitly-specified template argument lists.
+Consequently, an implementation can reject calls
+that specify an explicit template argument list.
 \end{note}
 
 \rSec1[algorithms.parallel]{Parallel algorithms}
@@ -353,7 +354,7 @@
 \tcode{BinaryOperation1},
 \tcode{BinaryOperation2}, and
 the operators used by the analogous overloads to these parallel algorithms
-that could be formed by the invocation
+that are formed by an invocation
 with the specified default predicate or operation (where applicable)
 shall not directly or indirectly modify objects via their arguments,
 nor shall they rely on the identity of the provided objects.
@@ -388,13 +389,13 @@
 where \tcode{is_trivially_copy_constructible_v<T>}
 and \tcode{is_trivially_destructible_v<T>} are \tcode{true}.
 \begin{note}
-This implies that user-supplied function objects should not rely on
+This implies that user-supplied function objects cannot rely on
 object identity of arguments for such input sequences.
-Users for whom the object identity of the arguments to these function objects
-is important should consider using a wrapping iterator
+If object identity of the arguments to these function objects
+is important, a wrapping iterator
 that returns a non-copied implementation object
-such as \tcode{reference_wrapper<T>}\iref{refwrap}
-or some equivalent solution.
+such as \tcode{reference_wrapper<T>}\iref{refwrap},
+or some equivalent solution, can be used.
 \end{note}
 
 \pnum
@@ -413,7 +414,7 @@
 unsequenced with respect to one another in the calling thread of execution.
 \begin{note}
 This means that multiple function object invocations
-may be interleaved on a single thread of execution,
+can be interleaved on a single thread of execution,
 which overrides the usual guarantee from \ref{intro.execution}
 that function executions do not overlap with one another.
 \end{note}
@@ -499,7 +500,7 @@
 or threads of execution implicitly created by the library;
 the latter will provide weakly parallel forward progress guarantees.
 \begin{note}
-This means that multiple function object invocations may be interleaved
+This means that multiple function object invocations can be interleaved
 on a single thread of execution,
 which overrides the usual guarantee from \ref{intro.execution}
 that function executions do not overlap with one another.
@@ -3152,7 +3153,7 @@
 starting from \tcode{first} and proceeding to \tcode{last - 1}.
 \begin{note}
 If the type of \tcode{first} meets the requirements of a mutable iterator,
-\tcode{f} may apply non-constant functions through the dereferenced iterator.
+\tcode{f} can apply non-constant functions through the dereferenced iterator.
 \end{note}
 
 \pnum
@@ -3187,7 +3188,7 @@
 every iterator in the range \range{first}{last}.
 \begin{note}
 If the type of \tcode{first} meets the requirements of a mutable iterator,
-\tcode{f} may apply non-constant functions through the dereferenced iterator.
+\tcode{f} can apply non-constant functions through the dereferenced iterator.
 \end{note}
 
 \pnum
@@ -3204,7 +3205,7 @@
 \pnum
 \begin{note}
 Does not return a copy of its \tcode{Function} parameter,
-since parallelization may not permit efficient state accumulation.
+since parallelization often does not permit efficient state accumulation.
 \end{note}
 \end{itemdescr}
 
@@ -3228,7 +3229,7 @@
 starting from \tcode{first} and proceeding to \tcode{last - 1}.
 \begin{note}
 If the result of \tcode{invoke(proj, *i)} is a mutable reference,
-\tcode{f} may apply non-constant functions.
+\tcode{f} can apply non-constant functions.
 \end{note}
 
 \pnum
@@ -3280,7 +3281,7 @@
 every iterator in the range \range{first}{first + n} in order.
 \begin{note}
 If the type of \tcode{first} meets the requirements of a mutable iterator,
-\tcode{f} may apply non-constant functions through the dereferenced iterator.
+\tcode{f} can apply non-constant functions through the dereferenced iterator.
 \end{note}
 
 \pnum
@@ -3319,7 +3320,7 @@
 every iterator in the range \range{first}{first + n}.
 \begin{note}
 If the type of \tcode{first} meets the requirements of a mutable iterator,
-\tcode{f} may apply non-constant functions through the dereferenced iterator.
+\tcode{f} can apply non-constant functions through the dereferenced iterator.
 \end{note}
 
 \pnum
@@ -3354,7 +3355,7 @@
 \range{first}{first + n} in order.
 \begin{note}
 If the result of \tcode{invoke(proj, *i)} is a mutable reference,
-\tcode{f} may apply non-constant functions.
+\tcode{f} can apply non-constant functions.
 \end{note}
 
 \pnum
@@ -4398,7 +4399,7 @@
 do not overlap.
 \begin{note}
 For the overload with an \tcode{ExecutionPolicy},
-there may be a performance cost
+there might be a performance cost
 if \tcode{iterator_traits<For\-ward\-It\-er\-ator1>::value_type}
 is not \oldconcept{\-Move\-Constructible} (\tref{cpp17.moveconstructible}).
 \end{note}
@@ -4461,7 +4462,7 @@
 Copies elements in the range \range{first}{last}
 into the range \range{result - $N$}{result}
 starting from \tcode{last - 1} and proceeding to \tcode{first}.%
-\footnote{\tcode{copy_backward} should be used instead of copy
+\footnote{\tcode{copy_backward} can be used instead of copy
 when \tcode{last} is in the range \range{result - $N$}{result}.}
 For each positive integer $n \le N$,
 performs \tcode{*(result - $n$) = *(last - $n$)}.
@@ -4612,7 +4613,7 @@
 Moves elements in the range \range{first}{last}
 into the range \range{result - $N$}{result}
 starting from \tcode{last - 1} and proceeding to \tcode{first}.%
-\footnote{\tcode{move_backward} should be used instead of move
+\footnote{\tcode{move_backward} can be used instead of move
 when \tcode{last} is in the range \range{result - $N$}{result}.}
 For each positive integer $n \le N$,
 performs \tcode{*(result - $n$) = $E$}.
@@ -5296,7 +5297,7 @@
 do not overlap.
 \begin{note}
 For the overloads with an \tcode{ExecutionPolicy},
-there may be a performance cost
+there might be a performance cost
 if \tcode{iterator_traits<ForwardIterator1>::value_type} does not meet
 the \oldconcept{\-Move\-Constructible} (\tref{cpp17.moveconstructible}) requirements.
 \end{note}
@@ -5483,7 +5484,7 @@
     \oldconcept{CopyAssignable} requirements.
     \begin{note}
     For the overloads with an \tcode{ExecutionPolicy},
-    there may be a performance cost
+    there might be a performance cost
     if the value type of \tcode{ForwardIterator1} does not meet both the
     \oldconcept{CopyConstructible} and \oldconcept{CopyAssignable} requirements.
     \end{note}
@@ -7019,7 +7020,7 @@
 
 \begin{note}
 For the overload with an \tcode{ExecutionPolicy},
-there may be a performance cost if \tcode{first}'s value type
+there might be a performance cost if \tcode{first}'s value type
 does not meet the \oldconcept{CopyConstructible} requirements.
 \end{note}
 
@@ -9537,7 +9538,7 @@
 that \tcode{exclusive_scan} excludes the $i^\text{th}$ input element
 from the $i^\text{th}$ sum.
 If \tcode{binary_op} is not mathematically associative,
-the behavior of \tcode{exclusive_scan} may be nondeterministic.
+the behavior of \tcode{exclusive_scan} might be nondeterministic.
 \end{note}
 \end{itemdescr}
 
@@ -9664,7 +9665,7 @@
 that \tcode{inclusive_scan} includes the $i^\text{th}$ input element
 in the $i^\text{th}$ sum.
 If \tcode{binary_op} is not mathematically associative,
-the behavior of \tcode{inclusive_scan} may be nondeterministic.
+the behavior of \tcode{inclusive_scan} might be nondeterministic.
 \end{note}
 \end{itemdescr}
 
@@ -9739,7 +9740,7 @@
 \tcode{transform_inclusive_scan} is that \tcode{trans\-form\-_\-exclusive_scan}
 excludes the $i^\text{th}$ input element from the $i^\text{th}$ sum.
 If \tcode{binary_op} is not mathematically associative,
-the behavior of \tcode{transform_exclusive_scan} may be nondeterministic.
+the behavior of \tcode{transform_exclusive_scan} might be nondeterministic.
 \tcode{transform_exclusive_scan}
 does not apply \tcode{unary_op} to \tcode{init}.
 \end{note}
@@ -9843,7 +9844,7 @@
 \tcode{transform_inclusive_scan} is that \tcode{trans\-form\-_\-inclusive_scan}
 includes the $i^\text{th}$ input element in the $i^\text{th}$ sum.
 If \tcode{binary_op} is not mathematically associative,
-the behavior of \tcode{transform_inclusive_scan} may be nondeterministic.
+the behavior of \tcode{transform_inclusive_scan} might be nondeterministic.
 \tcode{transform_inclusive_scan} does not
 apply \tcode{unary_op} to \tcode{init}.
 \end{note}

source/atomics.tex

@@ -528,7 +528,7 @@
 r2 = x.load(memory_order::relaxed);
 y.store(r2, memory_order::relaxed);
 \end{codeblock}
-should not produce \tcode{r1 == r2 == 42}, since the store of 42 to \tcode{y} is only
+this recommendation discourages producing \tcode{r1 == r2 == 42}, since the store of 42 to \tcode{y} is only
 possible if the store to \tcode{x} stores \tcode{42}, which circularly depends on the
 store to \tcode{y} storing \tcode{42}. Note that without this restriction, such an
 execution is possible.
@@ -636,11 +636,15 @@
 block\iref{intro.progress}.
 
 \pnum
-\begin{note}
-Operations that are lock-free should also be address-free. That is,
+\recommended
+Operations that are lock-free should also be address-free%
+\footnote{
+That is,
 atomic operations on the same memory location via two different addresses will
-communicate atomically. The implementation should not depend on any
-per-process state. This restriction enables communication  by memory that is
+communicate atomically.}.
+The implementation of these operations should not depend on any per-process state.
+\begin{note}
+This restriction enables communication by memory that is
 mapped into a process more than once and by memory that is shared between two
 processes.
 \end{note}
@@ -1602,7 +1606,7 @@
 is \tcode{false}.
 \begin{note}
 Type arguments that are
-not also statically initializable may be difficult to use.
+not also statically initializable might be difficult to use.
 \end{note}
 
 \pnum
@@ -3442,10 +3446,7 @@
 
 \pnum
 Operations on an object of type \tcode{atomic_flag} shall be lock-free.
-\begin{note}
-Hence
-the operations should also be address-free.
-\end{note}
+The operations should also be address-free.
 
 \pnum
 The \tcode{atomic_flag} type is a standard-layout struct.