Replace "could" and "might", Clauses 16-32. (#4386)

source/algorithms.tex

@@ -137,7 +137,7 @@
 the copying version is not included.
 For example, \tcode{sort_copy} is not included
 because the cost of sorting is much more significant,
-and users might as well do \tcode{copy} followed by \tcode{sort}.
+and users can invoke \tcode{copy} followed by \tcode{sort}.
 \end{footnote}
 When such a version is provided for \textit{algorithm} it is called
 \textit{algorithm\tcode{_copy}}.
@@ -8587,7 +8587,7 @@
 \pnum
 \begin{example}
 \tcode{ranges::lexicographical_compare(I1, S1, I2, S2, Comp, Proj1, Proj2)}
-could be implemented as:
+can be implemented as:
 \begin{codeblock}
 for ( ; first1 != last1 && first2 != last2 ; ++first1, (void) ++first2) {
   if (invoke(comp, invoke(proj1, *first1), invoke(proj2, *first2))) return true;
@@ -9536,7 +9536,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} might be nondeterministic.
+the behavior of \tcode{exclusive_scan} can be nondeterministic.
 \end{note}
 \end{itemdescr}
 
@@ -9663,7 +9663,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} might be nondeterministic.
+the behavior of \tcode{inclusive_scan} can be nondeterministic.
 \end{note}
 \end{itemdescr}
 
@@ -9738,7 +9738,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} might be nondeterministic.
+the behavior of \tcode{transform_exclusive_scan} can be nondeterministic.
 \tcode{transform_exclusive_scan}
 does not apply \tcode{unary_op} to \tcode{init}.
 \end{note}
@@ -9842,7 +9842,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} might be nondeterministic.
+the behavior of \tcode{transform_inclusive_scan} can be nondeterministic.
 \tcode{transform_inclusive_scan} does not
 apply \tcode{unary_op} to \tcode{init}.
 \end{note}

source/atomics.tex

@@ -770,7 +770,7 @@
 atomic operations applied through any other \tcode{atomic_ref}
 referencing the same object.
 \begin{note}
-Atomic operations or the \tcode{atomic_ref} constructor could acquire
+Atomic operations or the \tcode{atomic_ref} constructor can acquire
 a shared resource, such as a lock associated with the referenced object,
 to enable atomic operations to be applied to the referenced object.
 \end{note}
@@ -1608,7 +1608,7 @@
 is \tcode{false}.
 \begin{note}
 Type arguments that are
-not also statically initializable might be difficult to use.
+not also statically initializable can be difficult to use.
 \end{note}
 
 \pnum
@@ -1971,7 +1971,7 @@
 \pnum
 \begin{note}
 Under cases where the \tcode{memcpy} and \tcode{memcmp} semantics of the compare-and-exchange
-operations apply, the outcome might be failed comparisons for values that compare equal with
+operations apply, the comparisons can fail for values that compare equal with
 \tcode{operator==} if the value representation has trap bits or alternate
 representations of the same value. Notably, on implementations conforming to
 ISO/IEC/IEEE 60559, floating-point \tcode{-0.0} and \tcode{+0.0}

source/concepts.tex

@@ -394,7 +394,7 @@
 are modeled, then \tcode{T} and \tcode{U} share a
 \term{common reference type}, \tcode{C}.
 \begin{note}
-\tcode{C} could be the same as \tcode{T}, or \tcode{U}, or it could be a
+\tcode{C} can be the same as \tcode{T} or \tcode{U}, or can be a
 different type. \tcode{C} can be a reference type.
 \end{note}
 
@@ -437,8 +437,8 @@
 \tcode{C}, then \tcode{T} and \tcode{U} share a \term{common type},
 \tcode{C}.
 \begin{note}
-\tcode{C} could be the same as \tcode{T}, or \tcode{U}, or it could be a
-different type. \tcode{C} might not be unique.
+\tcode{C} can be the same as \tcode{T} or \tcode{U}, or can be a
+different type. \tcode{C} is not necessarily unique.
 \end{note}
 
 \begin{itemdecl}
@@ -1142,7 +1142,7 @@
 \pnum
 \begin{note}
 The \libconcept{semiregular} concept is modeled by types that behave similarly
-to built-in types like \tcode{int}, except that they might not
+to built-in types like \tcode{int}, except that they need not
 be comparable with \tcode{==}.
 \end{note}
 

source/containers.tex

@@ -65,7 +65,7 @@
 container's element type, not for internal types used by the container.
 \begin{note}
 This
-means, for example, that a node-based container might need to construct nodes containing
+means, for example, that a node-based container would need to construct nodes containing
 aligned buffers and call \tcode{construct} to place the element into the buffer.
 \end{note}
 

source/iostreams.tex

@@ -3696,7 +3696,7 @@
 \tcode{underflow}
 or
 \tcode{uflow}
-might fail by throwing an exception prematurely.
+can fail by throwing an exception prematurely.
 The intention is not only that the calls will not return
 \tcode{eof()}
 but that they will return ``immediately''.
@@ -3927,7 +3927,7 @@
 \tcode{traits::eof()}
 to indicate failure.
 Failure may occur because the input sequence could not be backed up, or if for some
-other reason the pointers could not be set consistent with the constraints.
+other reason the pointers cannot be set consistent with the constraints.
 \tcode{pbackfail()}
 is called only when put back has really failed.
 
@@ -7883,7 +7883,7 @@
 \pnum
 \begin{note}
 For efficiency reasons,
-stream buffer operations might violate invariants of \tcode{buf}
+stream buffer operations can violate invariants of \tcode{buf}
 while it is held encapsulated in the \tcode{basic_stringbuf},
 e.g., by writing to characters in the range
 \range{\tcode{buf.data() + buf.size()}}{\tcode{buf.data() + buf.capacity()}}.
@@ -12691,8 +12691,8 @@
 \effects
 Appends \tcode{path(x).native()} to the pathname in the native format.
 \begin{note}
-This directly manipulates the value of \tcode{native()}
-and might not be portable between operating systems.
+This directly manipulates the value of \tcode{native()},
+which is not necessarily portable between operating systems.
 \end{note}
 
 \pnum
@@ -13877,7 +13877,7 @@
 \tcode{file_type} constants
 to separately identify each of those additional file types \\ \rowsep
 \tcode{unknown} &
-The file exists but the type could not be determined \\
+The file exists but the type cannot be determined \\
 \end{floattable}
 
 \rSec3[fs.enum.copy.opts]{Enum class \tcode{copy_options}}
@@ -14942,7 +14942,7 @@
 \pnum
 \begin{note}
 If the directory structure being iterated over contains cycles
-then the end iterator might be unreachable.
+then it is possible that the end iterator is unreachable.
 \end{note}
 
 \rSec3[fs.rec.dir.itr.members]{Members}
@@ -15290,8 +15290,8 @@
 
 \pnum
 \begin{note}
-To resolve symlinks,
-or perform other sanitization which might require queries to secondary storage,
+To resolve symlinks
+or perform other sanitization that can involve queries to secondary storage,
 such as hard disks, consider \tcode{canonical}\iref{fs.op.canonical}.
 \end{note}
 
@@ -15865,7 +15865,7 @@
 \pnum
 \begin{note}
 The current path as returned by many operating systems is a dangerous
-  global variable. It might be changed unexpectedly by third-party or system
+  global variable and can be changed unexpectedly by third-party or system
   library functions, or by another thread.
 \end{note}
 \end{itemdescr}
@@ -15892,7 +15892,7 @@
 \pnum
 \begin{note}
 The current path for many operating systems is a dangerous
-  global state. It might be changed unexpectedly by a third-party or system
+  global state and can be changed unexpectedly by third-party or system
   library functions, or by another thread.
 \end{note}
 \end{itemdescr}
@@ -16380,8 +16380,8 @@
 
 \pnum
 \begin{note}
-A postcondition of \tcode{last_write_time(p) == new_time} is not specified since it might not hold for file systems
-  with coarse time granularity.
+A postcondition of \tcode{last_write_time(p) == new_time} is not specified
+because it does not necessarily hold for file systems with coarse time granularity.
 \end{note}
 \end{itemdescr}
 

source/iterators.tex

@@ -2079,7 +2079,7 @@
 The only valid use of an \tcode{operator*}
 is on the left side of the assignment statement.
 Assignment through the same value of the iterator happens only once.
-Equality and inequality might not be defined.
+Equality and inequality are not necessarily defined.
 \end{note}
 
 \rSec3[forward.iterators]{Forward iterators}
@@ -2637,12 +2637,9 @@
 
 \pnum
 \begin{example}
-For a program-defined iterator
-\tcode{BinaryTreeIterator},
-it could be included
-into the bidirectional iterator category by specializing the
-\tcode{iterator_traits}
-template:
+A program-defined iterator \tcode{BinaryTreeIterator}
+can be included into the bidirectional iterator category by
+specializing the \tcode{iterator_traits} template:
 
 \begin{codeblock}
 template<class T> struct iterator_traits<BinaryTreeIterator<T>> {

source/lib-intro.tex

@@ -308,20 +308,20 @@
 Failure to meet such a condition results in the function's silent non-viability.
 \end{note}
 \begin{example}
-An implementation might express such a condition
+An implementation can express such a condition
 via a \grammarterm{constraint-expression}\iref{temp.constr.decl}.
 \end{example}
 
 \item
 \mandates
 the conditions that, if not met, render the program ill-formed.
 \begin{example}
-An implementation might express such a condition
+An implementation can express such a condition
 via the \grammarterm{constant-expression}
 in a \grammarterm{static_assert-declaration}\iref{dcl.pre}.
 If the diagnostic is to be emitted only after the function
 has been selected by overload resolution,
-an implementation might express such a condition
+an implementation can express such a condition
 via a \grammarterm{constraint-expression}\iref{temp.constr.decl}
 and also define the function as deleted.
 \end{example}
@@ -1640,7 +1640,7 @@
 of type \tcode{P} may have an indeterminate value.
 \begin{note}
 Operations involving
-indeterminate values might cause undefined behavior.
+indeterminate values can cause undefined behavior.
 \end{note}
 
 \pnum
@@ -2733,7 +2733,7 @@
 (e.g., by calling the function with the argument \tcode{std::move(x)}), the program
 is effectively asking that function to treat that lvalue as a temporary object.
 The implementation
-is free to optimize away aliasing checks which might be needed if the argument was
+is free to optimize away aliasing checks which would possibly be needed if the argument was
 an lvalue.
 \end{note}
 \end{itemize}
@@ -2982,7 +2982,7 @@
 \pnum
 \begin{note}
 This means, for example, that implementations can't use an object with static storage duration for
-internal purposes without synchronization because it could cause a data race even in
+internal purposes without synchronization because doing so can cause a data race even in
 programs that do not explicitly share objects between threads.
 \end{note}
 

source/locales.tex

@@ -179,7 +179,7 @@
 
 \pnum
 \begin{example}
-An iostream \tcode{operator<<} might be implemented as:
+An iostream \tcode{operator<<} can be implemented as:%
 \begin{footnote}
 Note that in the call to \tcode{put},
 the stream is implicitly converted
@@ -197,7 +197,7 @@
       use_facet<time_put<charT, ostreambuf_iterator<charT, traits>>>(
         s.getloc()).put(s, s, s.fill(), &tmbuf, 'x').failed();
     if (failed)
-      s.setstate(s.badbit);     // might throw
+      s.setstate(s.badbit);     // can throw
   }
   return s;
 }
@@ -2106,7 +2106,7 @@
 \tcode{partial}             &   not all source characters converted \\
 \tcode{error}               &
 encountered a character in \range{from}{from_end}
-that it could not convert                                           \\
+that cannot be converted                                           \\
 \tcode{noconv}              &
 \tcode{internT} and \tcode{externT} are the same type, and input
 sequence is identical to converted sequence                         \\
@@ -3881,7 +3881,7 @@
 \effects
 Reads characters starting at \tcode{s}
 until it has extracted the (perhaps abbreviated) name of a weekday or month.
-If it finds an abbreviation that is followed by characters that could
+If it finds an abbreviation that is followed by characters that can
 match a full name, it continues reading until it matches the full name or
 fails.
 It sets the appropriate

source/numerics.tex

@@ -4011,7 +4011,7 @@
 \throws
 A value of an \impldef{exception type when \tcode{random_device} constructor fails} type
  derived from \tcode{exception}
- if the \tcode{random_device} could not be initialized.
+ if the \tcode{random_device} cannot be initialized.
 
 \pnum
 \remarks
@@ -4068,7 +4068,7 @@
 \throws
 A value of an \impldef{exception type when \tcode{random_device::operator()} fails}
  type derived from \tcode{exception}
- if a random number could not be obtained.
+ if a random number cannot be obtained.
 \end{itemdescr}
 
 

source/ranges.tex

@@ -1016,8 +1016,9 @@
 algorithms and making multiple passes over the range by repeated calls to
 \tcode{ranges::begin} and \tcode{ranges::end}.
 Since \tcode{ranges::begin} is not required to be equality-preserving
-when the return type does not model \libconcept{forward_iterator}, repeated calls
-might not return equal values or might not be well-defined.
+when the return type does not model \libconcept{forward_iterator},
+it is possible for repeated calls
+to not return equal values or to not be well-defined.
 \end{note}
 \end{itemdescr}
 
@@ -1104,7 +1105,7 @@
 \begin{note}
 \tcode{ranges::size(t)} is otherwise not required to be
 well-defined after evaluating \tcode{ranges::begin(t)}.
-For example, \tcode{ranges::size(t)} might be well-defined
+For example, it is possible for \tcode{ranges::size(t)} to be well-defined
 for a \libconcept{sized_range} whose iterator type
 does not model \libconcept{forward_iterator}
 only if evaluated before the first call to \tcode{ranges::begin(t)}.
@@ -1844,7 +1845,7 @@
 \end{codeblock}
 The call to \tcode{ranges::find} at \#1 returns \tcode{ranges::dangling}
 since \tcode{f()} is an rvalue \tcode{vector};
-the \tcode{vector} could potentially be destroyed
+it is possible for the \tcode{vector} to be destroyed
 before a returned iterator is dereferenced.
 However, the calls at \#2 and \#3 both return iterators
 since the lvalue \tcode{vec} and specializations of \tcode{subrange}