Replace "could" and "might", Clauses 1-15. (#4384)

Author: tkoeppe

source/basic.tex

@@ -699,7 +699,7 @@
 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} might result
+appearing in the type of \tcode{D} can result
 in the different declarations having distinct types, and
 \grammarterm{lambda-expression}{s} appearing in a default argument of \tcode{D}
 might still denote different types in different translation units.
@@ -1542,7 +1542,7 @@
 \begin{footnote}
 This
 refers to unqualified names following the class name;
-such a name might be used in a \grammarterm{base-specifier} or
+such a name can be used in a \grammarterm{base-specifier} or
 in the \grammarterm{member-specification} of the class definition.
 \end{footnote}
 outside of a complete-class context\iref{class.mem} of \tcode{X}
@@ -2859,7 +2859,7 @@
 \grammarterm{using-directive}{s}
 do not declare entities.
 Enumerators do not have linkage,
-but might serve as the name of an enumeration with linkage\iref{dcl.enum}.
+but can serve as the name of an enumeration with linkage\iref{dcl.enum}.
 \end{note}
 
 \pnum
@@ -2987,7 +2987,7 @@
 a specialization of a template
 whose (possibly instantiated) declaration is an exposure.
 \begin{note}
-The specialization might have been implicitly or explicitly instantiated.
+A specialization can be produced by implicit or explicit instantiation.
 \end{note}
 \end{itemize}
 
@@ -3472,7 +3472,7 @@
 lifetime ends there are significant restrictions on the use of the
 object, as described below, in~\ref{class.base.init} and
 in~\ref{class.cdtor}. Also, the behavior of an object under construction
-and destruction might not be the same as the behavior of an object whose
+and destruction can differ from the behavior of an object whose
 lifetime has started and not ended. \ref{class.base.init}
 and~\ref{class.cdtor} describe the behavior of an object during its periods
 of construction and destruction.
@@ -4229,7 +4229,7 @@
 \begin{note}
 The effect of using an invalid pointer value (including passing it to a
 deallocation function) is undefined, see~\ref{basic.stc}.
-This is true even if the unsafely-derived pointer value might compare equal to
+This is true even if the unsafely-derived pointer value would compare equal to
 some safely-derived pointer value.
 \end{note}
 It is
@@ -5329,8 +5329,8 @@
 \begin{note}
 A pointer past the end of an object\iref{expr.add}
 is not considered to point to an unrelated object
-of the object's type
-that might be located at that address.
+of the object's type,
+even if the unrelated object is located at that address.
 A pointer value becomes invalid
 when the storage it denotes
 reaches the end of its storage duration;
@@ -5731,7 +5731,7 @@
 \placeholder{B} or \placeholder{B} is sequenced before \placeholder{A}, but it is unspecified which.
 \begin{note}
 Indeterminately sequenced evaluations cannot overlap, but either
-could be executed first.
+can be executed first.
 \end{note}
 An expression \placeholder{X}
 is said to be sequenced before
@@ -5937,7 +5937,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 might observe modifications to different objects in inconsistent orders.
+threads can observe modifications to different objects in inconsistent orders.
 \end{note}
 
 \pnum
@@ -6355,7 +6355,7 @@
 \begin{example}
 A library I/O function that blocks until the I/O operation is complete can
 be considered to continuously check whether the operation is complete. Each
-such check might consist of one or more execution steps, for example using
+such check consists of one or more execution steps, for example using
 observable behavior of the abstract machine.
 \end{example}
 
@@ -6460,7 +6460,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 could also temporarily
+forward progress guarantee delegation on $C$, this can also temporarily
 provide a stronger forward progress guarantee to $C$.
 \end{note}
 

source/classes.tex

@@ -738,8 +738,8 @@
 The order of allocation of non-static data members
 with different access control
 is unspecified.
-Implementation alignment requirements might cause two adjacent members
-not to be allocated immediately after each other; so might requirements
+Implementation alignment requirements can cause two adjacent members
+not to be allocated immediately after each other; so can requirements
 for space for managing virtual functions\iref{class.virtual} and
 virtual base classes\iref{class.mi}.
 \end{note}
@@ -837,7 +837,7 @@
 if that member is not a bit-field. Its
 address is also the same as the address of each of its base class subobjects.
 \begin{note}
-There might therefore be unnamed padding within a standard-layout struct object
+There can therefore be unnamed padding within a standard-layout struct object
 inserted by an implementation, but
 not at its beginning, as necessary to achieve appropriate alignment.
 \end{note}
@@ -3613,9 +3613,9 @@
 
 \pnum
 \begin{note}
-A base class subobject might have a layout different
+A base class subobject can have a layout different
 from the layout of a most derived object of the same type. A base class
-subobject might have a polymorphic behavior\iref{class.cdtor}
+subobject can have a polymorphic behavior\iref{class.cdtor}
 different from the polymorphic behavior of a most derived object of the
 same type. A base class subobject can be of zero size;
 however, two subobjects that have the same class type and that belong to
@@ -3705,7 +3705,7 @@
 \end{importgraphic}
 
 In such lattices, explicit qualification can be used to specify which
-subobject is meant. The body of function \tcode{C::f} could refer to the
+subobject is meant. The body of function \tcode{C::f} can refer to the
 member \tcode{next} of each \tcode{L} subobject:
 \begin{codeblock}
 void C::f() { A::next = B::next; }      // well-formed
@@ -3792,8 +3792,8 @@
 \begin{footnote}
 If
 all virtual functions are immediate functions,
-the class is still polymorphic even though
-its internal representation might not otherwise require
+the class is still polymorphic even if
+its internal representation does not otherwise require
 any additions for that polymorphic behavior.
 \end{footnote}
 
@@ -4485,7 +4485,7 @@
 \pnum
 \begin{note}
 Even if the result of name lookup is unambiguous, use of a name found in
-multiple subobjects might still be
+multiple subobjects can still be
 ambiguous~(\ref{conv.mem}, \ref{expr.ref}, \ref{class.access.base}).
 \end{note}
 \begin{example}
@@ -4874,12 +4874,12 @@
 
 \pnum
 \begin{note}
-A member of a private base class might be inaccessible as an inherited
+A member of a private base class can be inaccessible as an inherited
 member name, but accessible directly.
 Because of the rules on pointer conversions\iref{conv.ptr} and
 explicit casts~(\ref{expr.type.conv}, \ref{expr.static.cast}, \ref{expr.cast}),
 a conversion from a pointer to a derived class to a pointer
-to an inaccessible base class might be ill-formed if an implicit conversion
+to an inaccessible base class can be ill-formed if an implicit conversion
 is used, but well-formed if an explicit cast is used.
 For example,
 
@@ -6579,7 +6579,7 @@
 requiring a constant expression\iref{expr.const}
 and in constant initialization\iref{basic.start.static}.
 \begin{note}
-Copy elision might be performed
+It is possible that copy elision is performed
 if the same expression
 is evaluated in another context.
 \end{note}
@@ -7247,7 +7247,7 @@
 \pnum
 Access to the deallocation function is checked statically.
 \begin{note}
-Hence, even though a different one might actually be executed,
+Hence, even if a different one is actually executed,
 the statically visible deallocation function is required to be accessible.
 \end{note}
 \begin{example}

source/declarations.tex

@@ -3596,7 +3596,7 @@
 For example,
 the function
 \tcode{fpif}
-above could have been declared
+above can be declared
 \begin{codeblock}
 typedef int  IFUNC(int);
 IFUNC*  fpif(int);
@@ -4610,7 +4610,7 @@
 this is the defining declaration\iref{basic.def} of the variable,
 but the initializing declaration
 of a non-inline static data member\iref{class.static.data}
-might be the declaration within the class definition
+can be the declaration within the class definition
 and not the definition at namespace scope.
 \end{note}
 
@@ -5828,7 +5828,7 @@
 ill-formed\iref{class.base.init}.
 \end{example}
 \begin{note}
-The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer could be so allocated.
+The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer can be so allocated.
 \end{note}
 
 \pnum
@@ -5863,8 +5863,8 @@
 int x = 999;                    // \tcode{x} is not a constant expression
 const int y = 999;
 const int z = 99;
-char c1 = x;                    // OK, though it might narrow (in this case, it does narrow)
-char c2{x};                     // error: might narrow
+char c1 = x;                    // OK, though it potentially narrows (in this case, it does narrow)
+char c2{x};                     // error: potentially narrows
 char c3{y};                     // error: narrows (assuming \tcode{char} is 8 bits)
 char c4{z};                     // OK: no narrowing needed
 unsigned char uc1 = {5};        // OK: no narrowing needed
@@ -5873,7 +5873,7 @@
 signed int si1 =
   { (unsigned int)-1 };         // error: narrows
 int ii = {2.0};                 // error: narrows
-float f1 { x };                 // error: might narrow
+float f1 { x };                 // error: potentially narrows
 float f2 { 7 };                 // OK: 7 can be exactly represented as a \tcode{float}
 bool b = {"meow"};              // error: narrows
 int f(int);

source/expressions.tex

@@ -1685,7 +1685,7 @@
 or operator template is the \grammarterm{requires-clause}
 of the \grammarterm{lambda-declarator}, if any.
 \begin{note}
-The function call operator template for a generic lambda might be
+The function call operator template for a generic lambda can be
 an abbreviated function template\iref{dcl.fct}.
 \end{note}
 \begin{example}
@@ -1951,7 +1951,7 @@
 operators otherwise\iref{class.copy.assign}.
 \begin{note}
 These special member functions are implicitly defined as
-usual, and might therefore be defined as deleted.
+usual, which can result in them being defined as deleted.
 \end{note}
 
 \pnum
@@ -2159,20 +2159,20 @@
 
   auto g2 = [=](auto a) {
     int selector[sizeof(a) == 1 ? 1 : 2]{};
-    f(x, selector);             // OK: captures \tcode{x}, might call \#1 or \#2
+    f(x, selector);             // OK: captures \tcode{x}, can call \#1 or \#2
   };
 
   auto g3 = [=](auto a) {
     typeid(a + x);              // captures \tcode{x} regardless of whether \tcode{a + x} is an unevaluated operand
   };
 }
 \end{codeblock}
-Within \tcode{g1}, an implementation might optimize away
+Within \tcode{g1}, an implementation can optimize away
 the capture of \tcode{x} as it is not odr-used.
 \end{example}
 \begin{note}
 The set of captured entities is determined syntactically,
-and entities might be implicitly captured
+and entities are implicitly captured
 even if the expression denoting a local entity
 is within a discarded statement\iref{stmt.if}.
 \begin{example}
@@ -2875,7 +2875,7 @@
 The \tcode{>} token following the
 \grammarterm{type-id} in a \tcode{dynamic_cast},
 \tcode{static_cast}, \tcode{reinterpret_cast}, or
-\tcode{const_cast} might be the product of replacing a
+\tcode{const_cast} can be the product of replacing a
 \tcode{>>} token by two consecutive \tcode{>}
 tokens\iref{temp.names}.
 \end{note}
@@ -3051,7 +3051,7 @@
 or destructor for a function parameter throws an exception, the search
 for a handler starts in the scope of the calling function; in
 particular, if the function called has a \grammarterm{function-try-block}\iref{except.pre}
-with a handler that could handle the exception,
+with a handler that can handle the exception,
 this handler is not considered.
 \end{example}
 
@@ -4143,7 +4143,7 @@
 is not limited to conversions that cast away a
 const-qualifier.
 \end{footnote}
-might produce undefined behavior\iref{dcl.type.cv}.
+can produce undefined behavior\iref{dcl.type.cv}.
 \end{note}
 
 \pnum
@@ -4319,7 +4319,7 @@
 The address of an overloaded function\iref{over} can be taken
 only in a context that uniquely determines which version of the
 overloaded function is referred to (see~\ref{over.over}).
-Since the context might determine whether the operand is a static or
+Since the context can affect whether the operand is a static or
 non-static member function, the context can also affect whether the
 expression has type ``pointer to function'' or ``pointer to member
 function''.
@@ -4990,7 +4990,7 @@
 versions\iref{class.free}.
 The set of allocation and deallocation functions that can be called
 by a \grammarterm{new-expression}
-could include functions that do not perform allocation or deallocation;
+can include functions that do not perform allocation or deallocation;
 for example, see \ref{new.delete.placement}.
 \end{note}
 
@@ -5246,7 +5246,7 @@
 \indextext{\idxcode{new}!exception and}%
 If any part of the object initialization described above%
 \begin{footnote}
-This might
+This can
 include evaluating a \grammarterm{new-initializer} and/or calling
 a constructor.
 \end{footnote}
@@ -6828,7 +6828,7 @@
 \begin{note}
 This restriction applies to the relationship
 between the left and right sides of the assignment operation; it is not a
-statement about how the target of the assignment might be aliased in general.
+statement about how the target of the assignment can be aliased in general.
 See~\ref{basic.lval}.
 \end{note}
 
@@ -7411,7 +7411,7 @@
 has constant initialization\iref{basic.start.static}.
 \begin{footnote}
 Testing this condition
-might involve a trial evaluation of its initializer as described above.
+can involve a trial evaluation of its initializer as described above.
 \end{footnote}
 \begin{example}
 \begin{codeblock}
@@ -7426,7 +7426,7 @@
 
 constexpr int f() {
   const int n = std::is_constant_evaluated() ? 13 : 17; // \tcode{n} is 13
-  int m = std::is_constant_evaluated() ? 13 : 17;       // \tcode{m} might be 13 or 17 (see below)
+  int m = std::is_constant_evaluated() ? 13 : 17;       // \tcode{m} can be 13 or 17 (see below)
   char arr[n] = {}; // char[13]
   return m + sizeof(arr);
 }
@@ -7454,14 +7454,14 @@
 \item
 an immediate subexpression of a \grammarterm{braced-init-list},
 \begin{footnote}
-Constant evaluation might be necessary to determine whether a narrowing conversion is performed\iref{dcl.init.list}.
+In some cases, constant evaluation is needed to determine whether a narrowing conversion is performed\iref{dcl.init.list}.
 \end{footnote}
 
 \item
 an expression of the form \tcode{\&} \grammarterm{cast-expression}
 that occurs within a templated entity,
 \begin{footnote}
-Constant evaluation might be necessary to determine whether such an expression is value-dependent\iref{temp.dep.constexpr}.
+In some cases, constant evaluation is needed to determine whether such an expression is value-dependent\iref{temp.dep.constexpr}.
 \end{footnote}
 or