Replace 'encouraged' with 'should'.

Consistent with ISO Directives, Part 2, encouragement for
implementations is supposed to use 'should', not 'encouraged'.

Fixes #1601.

source/declarations.tex

@@ -4001,7 +4001,7 @@
 a warning that an implementation might otherwise issue
 for a case or default label that is reachable
 from another case or default label along some path of execution.
-Implementations are encouraged to issue a warning
+Implementations should issue a warning
 if a fallthrough statement is not dynamically reachable.
 \end{note}
 
@@ -4042,7 +4042,7 @@
 \pnum
 \begin{note}
 For an entity marked \tcode{maybe_unused}, implementations
-are encouraged not to emit a warning that the entity is unused, or
+should not emit a warning that the entity is unused, or
 that the entity is used despite the presence of the attribute.
 \end{note}
 
@@ -4062,7 +4062,7 @@
   assert(b);
 }
 \end{codeblock}
-Implementations are encouraged not to warn that \tcode{b} is unused,
+Implementations should not warn that \tcode{b} is unused,
 whether or not \tcode{NDEBUG} is defined.
 \end{example}
 
@@ -4084,7 +4084,7 @@
 marked \tcode{nodiscard}. Appearance of a nodiscard call as
 a potentially-evaluated discarded-value expression (Clause~\ref{expr})
 is discouraged unless explicitly cast to \tcode{void}.
-Implementations are encouraged to issue a warning in such cases.
+Implementations should issue a warning in such cases.
 This is typically because discarding the return value
 of a nodiscard call has surprising consequences.
 \end{note}
@@ -4121,7 +4121,7 @@
 \pnum
 If a function \tcode{f} is called where \tcode{f} was previously declared with the \tcode{noreturn}
 attribute and \tcode{f} eventually returns, the behavior is undefined. \begin{note} The function may
-terminate by throwing an exception. \end{note} \begin{note} Implementations are encouraged to issue a
+terminate by throwing an exception. \end{note} \begin{note} Implementations should issue a
 warning if a function marked \tcode{[[noreturn]]} might return. \end{note}
 
 \pnum

source/expressions.tex

@@ -5233,7 +5233,7 @@
 imposes no restrictions on the accuracy of floating-point operations, it is unspecified whether the
 evaluation of a floating-point expression during translation yields the same result as the
 evaluation of the same expression (or the same operations on the same values) during program
-execution.\footnote{Nonetheless, implementations are encouraged to provide consistent results,
+execution.\footnote{Nonetheless, implementations should provide consistent results,
 irrespective of whether the evaluation was performed during translation and/or during program
 execution.} \begin{example}
 

source/intro.tex

@@ -1609,7 +1609,7 @@
 \tcode{std::thread}~(\ref{thread.thread.class}) provide concurrent forward progress
 guarantees.
 \begin{note}
-General-purpose implementations are encouraged to provide these guarantees.
+General-purpose implementations should provide these guarantees.
 \end{note}
 
 \pnum

source/iostreams.tex

@@ -410,7 +410,7 @@
 The objects are constructed and the associations are established at some
 time prior to or during the first time an object of class
 \tcode{ios_base::Init} is constructed, and in any case before the body
-of \tcode{main}~(\ref{basic.start.main}) begins execution.\footnote{If it is possible for them to do so, implementations are encouraged to
+of \tcode{main}~(\ref{basic.start.main}) begins execution.\footnote{If it is possible for them to do so, implementations should
 initialize the objects earlier than required.}
 The objects are not destroyed during program execution.\footnote{Constructors and destructors for static objects can
 access these objects to read input from
@@ -9948,10 +9948,10 @@
 operating system or other APIs. \end{note}
 
 \pnum
-Implementations are encouraged to provide such behavior as it is defined by
+Implementations should provide such behavior as it is defined by
 POSIX. Implementations shall document any behavior that differs from the
 behavior defined by POSIX. Implementations that do not support exact POSIX
-behavior are encouraged to provide behavior as close to POSIX behavior as is reasonable given the
+behavior should provide behavior as close to POSIX behavior as is reasonable given the
 limitations of actual operating systems and file systems. If an implementation cannot provide any
 reasonable behavior, the implementation shall report an error as specified in~\ref{fs.err.report}.
 \begin{note} This allows users to rely on an exception being thrown or
@@ -12335,7 +12335,7 @@
 \begin{itemdescr}
 \pnum
 \returns A string containing \tcode{runtime_error::what()}. The exact format is unspecified.
-  Implementations are encouraged but not required to include \tcode{path1.native_string()}
+  Implementations should include \tcode{path1.native_string()}
   if not empty, \tcode{path2.native_string()} if not empty, and \tcode{system_error::what()} strings in the returned
   string.
 \end{itemdescr}
@@ -12744,7 +12744,7 @@
 such as hard link count, status, symlink status, file size, and last write time.
 
 \pnum
-Implementations are encouraged to store such additional file attributes
+Implementations should store such additional file attributes
 during directory iteration if their values are available
 and storing the values would allow the implementation to eliminate file system accesses
 by \tcode{directory_entry} observer functions~(\ref{fs.op.funcs}).
@@ -15226,8 +15226,8 @@
 \postconditions The returned path is in normal form~(\ref{fs.def.normal.form}).
 
 \pnum
-\remarks Implementations are encouraged
-  to avoid unnecessary normalization such as
+\remarks Implementations should
+  avoid unnecessary normalization such as
   when \tcode{canonical} has already been called on the entirety of \tcode{p}.
 
 \pnum

source/lib-intro.tex

@@ -2974,10 +2974,10 @@
 operating system} \tcode{error_category} object for errors originating elsewhere.
 The implementation shall define the possible values of \tcode{value()} for each of these
 error categories. \begin{example} For operating systems that are based on POSIX,
-implementations are encouraged to define the \tcode{std::system_category()} values as
+implementations should define the \tcode{std::system_category()} values as
 identical to the POSIX \tcode{errno} values, with additional values as defined by the
 operating system's documentation. Implementations for operating systems that are not
-based on POSIX are encouraged to define values identical to the operating system's
+based on POSIX should define values identical to the operating system's
 values. For errors that do not originate from the operating system, the implementation
 may provide enums for the associated values. \end{example}
 

source/locales.tex

@@ -4074,7 +4074,7 @@
 except that the sequence of characters produced for those specifiers
 that are described as depending on the C locale are instead \impldef{formatted character
 sequence generated by \tcode{time_put::do_put} in C
-locale}.\footnote{Implementations are encouraged to refer to other standards
+locale}.\footnote{Implementations should refer to other standards
 such as POSIX
 for these definitions.}
 

source/special.tex

@@ -543,7 +543,7 @@
 S a { 1, {2,3} };
 S* p = new S{ 1, {2,3} };   // Creates dangling reference
 \end{codeblock}
-\end{example} \begin{note} This may introduce a dangling reference, and implementations are encouraged to issue a warning in such a case. \end{note}
+\end{example} \begin{note} This may introduce a dangling reference, and implementations should issue a warning in such a case. \end{note}
 \end{itemize}
 
 \pnum

source/strings.tex

@@ -5293,7 +5293,7 @@
 
 \pnum
 Member functions in this section have complexity \bigoh{\tcode{size() * str.size()}} at worst,
-although implementations are encouraged to do better.
+although implementations should do better.
 
 \pnum
 Each member function of the form

source/threads.tex

@@ -4217,7 +4217,7 @@
 is undefined.
 \begin{note} It is valid to move from a future object for which \tcode{valid() == false}.
 \end{note}
-\begin{note} Implementations are encouraged to detect this case and throw an object of type
+\begin{note} Implementations should detect this case and throw an object of type
 \tcode{future_error} with an error condition of \tcode{future_errc::no_state}. \end{note}
 
 \indexlibrary{\idxcode{future}}%
@@ -4502,7 +4502,7 @@
 \tcode{valid()} on a \tcode{shared_future} object for which \tcode{valid() == false} is undefined.
 \begin{note} It is valid to copy or move from a \tcode{shared_future}
 object for which \tcode{valid()} is \tcode{false}. \end{note}
-\begin{note} Implementations are encouraged to detect this case and throw an object of type
+\begin{note} Implementations should detect this case and throw an object of type
 \tcode{future_error} with an error condition of \tcode{future_errc::no_state}. \end{note}
 
 \indexlibrary{\idxcode{shared_future}}%

source/utilities.tex

@@ -14598,7 +14598,7 @@
 a specialization of \tcode{reference_wrapper} or
 a function pointer. Otherwise, may throw \tcode{bad_alloc}
 or any exception thrown by the copy constructor of the stored callable object.
-\begin{note} Implementations are encouraged to avoid the use of
+\begin{note} Implementations should avoid the use of
 dynamically allocated memory for small callable objects, for example, where
 \tcode{f}'s target is an object holding only a pointer or reference
 to an object and a member function pointer. \end{note}
@@ -14622,7 +14622,7 @@
 a function pointer. Otherwise, may throw \tcode{bad_alloc} or
 any exception thrown by the copy or move constructor
 of the stored callable object.
-\begin{note} Implementations are encouraged to avoid the use of
+\begin{note} Implementations should avoid the use of
 dynamically allocated memory for small callable objects, for example,
 where \tcode{f}'s target is an object holding only a pointer or reference
 to an object and a member function pointer. \end{note}
@@ -14654,7 +14654,7 @@
 \pnum
 Otherwise, \tcode{*this} targets a copy of \tcode{f}
 initialized with \tcode{std::move(f)}.
-\begin{note} Implementations are encouraged to avoid the use of
+\begin{note} Implementations should avoid the use of
 dynamically allocated memory for small callable objects, for example,
 where \tcode{f} is an object holding only a pointer or
 reference to an object and a member function pointer. \end{note}