[std] Replace 'may' in notes.

Partially addresses ISO/CS 017 (C++20 DIS)

source/algorithms.tex

@@ -262,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}
@@ -389,7 +389,7 @@
 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
@@ -414,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}
@@ -500,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.
@@ -3153,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
@@ -3188,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
@@ -3205,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}
 
@@ -3229,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
@@ -3278,7 +3278,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
@@ -3314,7 +3314,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
@@ -3349,7 +3349,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
@@ -4389,7 +4389,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}
@@ -5287,7 +5287,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}
@@ -5474,7 +5474,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}
@@ -7009,7 +7009,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}
 
@@ -9527,7 +9527,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}
 
@@ -9654,7 +9654,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}
 
@@ -9729,7 +9729,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}
@@ -9833,7 +9833,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,8 +636,9 @@
 block\iref{intro.progress}.
 
 \pnum
+Operations that are lock-free should also be address-free.
 \begin{note}
-Operations that are lock-free should also be address-free. That is,
+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
@@ -1603,7 +1604,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
@@ -3443,10 +3444,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.

source/basic.tex

@@ -692,10 +692,10 @@
 The entity is still declared in multiple translation units, and \ref{basic.link}
 still applies to these declarations. In particular,
 \grammarterm{lambda-expression}{s}\iref{expr.prim.lambda}
-appearing in the type of \tcode{D} may result
+appearing in the type of \tcode{D} might result
 in the different declarations having distinct types, and
 \grammarterm{lambda-expression}{s} appearing in a default argument of \tcode{D}
-may still denote different types in different translation units.
+might still denote different types in different translation units.
 \end{note}
 
 \pnum
@@ -822,9 +822,9 @@
 a name is introduced, which is not necessarily the same as the region in
 which the declaration occurs. In particular,
 \grammarterm{elaborated-type-specifier}{s}\iref{dcl.type.elab} and
-friend declarations\iref{class.friend} may introduce a (possibly not
+friend declarations\iref{class.friend} can introduce a (possibly not
 visible) name into an enclosing namespace; these restrictions apply to
-that region. Local extern declarations\iref{basic.link} may introduce
+that region. Local extern declarations\iref{basic.link} can introduce
 a name into the declarative region where the declaration appears and
 also introduce a (possibly not visible) name into an enclosing
 namespace; these restrictions apply to both regions.
@@ -2834,7 +2834,7 @@
 \grammarterm{using-directive}{s}
 do not declare entities.
 Enumerators do not have linkage,
-but may serve as the name of an enumeration with linkage\iref{dcl.enum}.
+but might serve as the name of an enumeration with linkage\iref{dcl.enum}.
 \end{note}
 
 \pnum
@@ -4538,7 +4538,7 @@
 
 \item A temporary bound to a reference in a \grammarterm{new-initializer}\iref{expr.new} persists until the completion of the full-expression containing the \grammarterm{new-initializer}.
 \begin{note}
-This may introduce a dangling reference.
+This might introduce a dangling reference.
 \end{note}
 \begin{example}
 \begin{codeblock}
@@ -5809,7 +5809,7 @@
 initial value of the object, a value assigned to the object by $T$, or a
 value assigned to the object by another thread, according to the rules below.
 \begin{note}
-In some cases, there may instead be undefined behavior. Much of this
+In some cases, there might instead be undefined behavior. Much of this
 subclause is motivated by the desire to support atomic operations with explicit
 and detailed visibility constraints. However, it also implicitly supports a
 simpler view for more restricted programs.
@@ -5852,7 +5852,7 @@
 There is a separate order for each
 atomic object. There is no requirement that these can be combined into a single
 total order for all objects. In general this will be impossible since different
-threads may observe modifications to different objects in inconsistent orders.
+threads might observe modifications to different objects in inconsistent orders.
 \end{note}
 
 \pnum
@@ -6181,14 +6181,14 @@
 execution would not have encountered a data race. This includes implementations
 of data member assignment that overwrite adjacent members in separate memory
 locations. Reordering of atomic loads in cases in which the atomics in question
-may alias is also generally precluded, since this may violate the coherence
+might alias is also generally precluded, since this could violate the coherence
 rules.
 \end{note}
 
 \pnum
 \begin{note}
 Transformations that introduce a speculative read of a potentially
-shared memory location may not preserve the semantics of the \Cpp{} program as
+shared memory location might not preserve the semantics of the \Cpp{} program as
 defined in this document, since they potentially introduce a data race. However,
 they are typically valid in the context of an optimizing compiler that targets a
 specific machine with well-defined semantics for data races. They would be
@@ -6224,7 +6224,7 @@
   a lock-free execution in that thread shall complete.
   \begin{note}
     Concurrently executing threads
-    may prevent progress of a lock-free execution.
+    might prevent progress of a lock-free execution.
     For example,
     this situation can occur
     with load-locked store-conditional implementations.
@@ -6238,7 +6238,7 @@
     to provide absolute guarantees to this effect,
     since repeated and particularly inopportune interference
     from other threads
-    may prevent forward progress,
+    could prevent forward progress,
     e.g.,
     by repeatedly stealing a cache line
     for unrelated purposes
@@ -6306,9 +6306,7 @@
 \tcode{std::thread}\iref{thread.thread.class}
 or \tcode{std::jthread}\iref{thread.jthread.class}
 provide concurrent forward progress guarantees.
-\begin{note}
 General-purpose implementations should provide these guarantees.
-\end{note}
 
 \pnum
 \indextext{forward progress guarantees!parallel}%
@@ -6346,7 +6344,7 @@
 guarantees, which in turn are stronger than weakly parallel forward progress
 guarantees.
 \begin{note}
-For example, some kinds of synchronization between threads of execution may only
+For example, some kinds of synchronization between threads of execution might only
 make progress if the respective threads of execution provide parallel forward progress
 guarantees, but will fail to make progress under weakly parallel guarantees.
 \end{note}
@@ -6377,7 +6375,7 @@
 stronger forward progress guarantee for a certain amount of time, due to a
 second thread of execution $A$ being blocked on it with forward
 progress guarantee delegation. In turn, if $B$ then blocks with
-forward progress guarantee delegation on $C$, this may also temporarily
+forward progress guarantee delegation on $C$, this could also temporarily
 provide a stronger forward progress guarantee to $C$.
 \end{note}
 
@@ -6565,10 +6563,10 @@
 inline double fd() { return 1.0; }
 extern double d1;
 double d2 = d1;     // unspecified:
-                    // may be statically initialized to \tcode{0.0} or
+                    // either statically initialized to \tcode{0.0} or
                     // dynamically initialized to \tcode{0.0} if \tcode{d1} is
                     // dynamically initialized, or \tcode{1.0} otherwise
-double d1 = fd();   // may be initialized statically or dynamically to \tcode{1.0}
+double d1 = fd();   // either initialized statically or dynamically to \tcode{1.0}
 \end{codeblock}
 \end{note}