diff --git a/source/declarations.tex b/source/declarations.tex
index 141298caae..0bde04cd6b 100644
--- a/source/declarations.tex
+++ b/source/declarations.tex
@@ -924,14 +924,11 @@
 \end{itemize}
 
 \pnum
-For a constexpr function or constexpr constructor
-that is neither defaulted nor a template,
-if no argument values exist such that
-an invocation of the function or constructor could be an evaluated subexpression of a core
-constant expression\iref{expr.const}, or,
-for a constructor, an evaluated subexpression of
-the initialization full-expression of some constant-initialized object\iref{basic.start.static},
-the program is ill-formed, no diagnostic required.
+A constexpr function that is neither defaulted nor a template
+is ill-formed, no diagnostic required,
+if it is not possible for an evaluation of an invocation of the function
+to be performed
+while evaluating any valid manifestly constant-evaluated expression.
 \begin{example}
 \begin{codeblock}
 constexpr int f(bool b)
@@ -1238,7 +1235,7 @@
 Redundant cv-qualifications are ignored.
 \begin{note}
 For example,
-these could be introduced by typedefs.
+these can be introduced by typedefs.
 \end{note}
 
 \pnum
@@ -1317,9 +1314,9 @@
 \indextext{\idxcode{volatile}!implementation-defined}%
 \begin{note}
 \tcode{volatile} is a hint to the implementation to avoid aggressive
-optimization involving the object because the value of the object might
-be changed by means undetectable by an implementation.
-Furthermore, for some implementations, \tcode{volatile} might indicate that
+optimization involving the object because it is possible for the value of the object
+to change by means undetectable by an implementation.
+Furthermore, for some implementations, \tcode{volatile} can indicate that
 special hardware instructions are required to access the object.
 See~\ref{intro.execution} for detailed semantics. In general, the
 semantics of \tcode{volatile} are intended to be the same in \Cpp{} as
@@ -2400,8 +2397,9 @@
 a redundant set of parentheses around a parameter name and an object declaration
 with a function-style cast as the initializer.
 Just as for the ambiguities mentioned in~\ref{stmt.ambig},
-the resolution is to consider any construct that could possibly
-be a declaration a declaration.
+the resolution is to consider any construct
+that matches the syntax of a declaration
+to be a declaration.
 \begin{note}
 A declaration can be explicitly disambiguated by adding parentheses
 around the argument.
@@ -2428,10 +2426,9 @@
 An ambiguity can arise from the similarity between a function-style
 cast and a
 \grammarterm{type-id}.
-The resolution is that any construct that could possibly be a
-\grammarterm{type-id}
-in its syntactic context shall be considered a
-\grammarterm{type-id}.
+The resolution is that any construct
+that matches the syntax of a \grammarterm{type-id}
+is interpreted as a \grammarterm{type-id}.
 \begin{example}
 \begin{codeblock}
 template <class T> struct X {};
@@ -3604,7 +3601,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);
@@ -4602,9 +4599,9 @@
 no constructor of the object's class
 is invoked for the initialization.
 \begin{note}
-Such an object might have been value-initialized
-or initialized by aggregate initialization\iref{dcl.init.aggr}
-or by an inherited constructor\iref{class.inhctor.init}.
+Such an object can use value-initializion,
+aggregate initialization\iref{dcl.init.aggr},
+or initialization by an inherited constructor\iref{class.inhctor.init}.
 \end{note}
 Destroying an object of class type invokes the destructor of the class.
 Destroying a scalar type has no effect other than
@@ -4620,7 +4617,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}
 
@@ -5833,7 +5830,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
@@ -5868,8 +5865,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
@@ -5878,7 +5875,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);
@@ -8197,7 +8194,7 @@
 \begin{note}
 Some of the properties associated with an entity with language linkage
 are specific to each implementation and are not described here. For
-example, a particular language linkage might be associated with a
+example, a particular language linkage can be associated with a
 particular form of representing names of objects and functions with
 external linkage, or with a particular calling convention, etc.
 \end{note}
@@ -8749,7 +8746,7 @@
 \pnum
 \begin{note}
 The \tcode{carries_dependency} attribute does not change the meaning of the
-program, but might result in generation of more efficient code.
+program, but can result in generation of more efficient code.
 \end{note}
 
 \pnum
@@ -8792,9 +8789,10 @@
 hardware memory ordering instructions (a.k.a.\ fences).
 Function \tcode{g}'s second parameter has a \tcode{carries_dependency} attribute,
 but its first parameter does not. Therefore, function \tcode{h}'s first call to
-\tcode{g} carries a dependency into \tcode{g}, but its second call does not. The
-implementation might need to insert a fence prior to the second call to
-\tcode{g}.
+\tcode{g} carries a dependency into \tcode{g}, but its second call does not.
+It is possible
+that the implementation needs to insert a fence
+prior to the second call to \tcode{g}.
 \end{example}
 \indextext{attribute|)}%
 \indextext{declaration|)}
@@ -8876,7 +8874,7 @@
 \pnum
 \recommended
 The use of a fallthrough statement should suppress
-a warning that an implementation might otherwise issue
+any warning that an implementation would otherwise issue
 for a case or default label that is reachable
 from another case or default label along some path of execution.
 Implementations should issue a warning
@@ -9139,7 +9137,7 @@
 \pnum
 \recommended
 Implementations should issue a
-warning if a function marked \tcode{[[noreturn]]} might return.
+warning if a function marked \tcode{[[noreturn]]} can return.
 
 \pnum
 \begin{example}
@@ -9190,6 +9188,6 @@
 };
 \end{codeblock}
 Here, \tcode{hasher}, \tcode{pred}, and \tcode{alloc}
-could have the same address as \tcode{buckets}
+can have the same address as \tcode{buckets}
 if their respective types are all empty.
 \end{example}