Replace "this International Standard" with "this document" when

referring to the document as a body of text.

Cases where that phrasing is used to compare this standard to other
revisions of the C++ standard retain this phrasing for clarity.

Fixes ISO 20 (C++17 DIS)

Author: zygoloid

source/algorithms.tex

@@ -1231,7 +1231,7 @@
 
 \rSec2[algorithms.parallel.defns]{Terms and definitions}
 \pnum
-A \defn{parallel algorithm} is a function template listed in this International Standard with
+A \defn{parallel algorithm} is a function template listed in this document with
 a template parameter named \tcode{ExecutionPolicy}.
 
 \pnum

source/basic.tex

@@ -3273,8 +3273,8 @@
 describes the lifetime of base and member subobjects. \end{note}
 
 \pnum
-The properties ascribed to objects and references throughout this International
-Standard apply for a given object or reference only during its lifetime. \begin{note}
+The properties ascribed to objects and references throughout this document
+apply for a given object or reference only during its lifetime. \begin{note}
 In particular, before the lifetime of an object starts and after its
 lifetime ends there are significant restrictions on the use of the
 object, as described below, in~\ref{class.base.init} and
@@ -3849,8 +3849,8 @@
 \pnum
 \indextext{Boolean type}%
 Values of type \tcode{bool} are either \tcode{true} or
-\tcode{false}.\footnote{Using a \tcode{bool} value in ways described by this International
-Standard as ``undefined'', such as by examining the value of an
+\tcode{false}.\footnote{Using a \tcode{bool} value in ways described by this document
+as ``undefined'', such as by examining the value of an
 uninitialized automatic object, might cause it to behave as if it is
 neither \tcode{true} nor \tcode{false}.}
 \begin{note} There are no \tcode{signed}, \tcode{unsigned}, \tcode{short},
@@ -3875,7 +3875,7 @@
 begin with 1, and are multiplied by successive integral power of 2,
 except perhaps for the bit with the highest position. (Adapted from the
 \doccite{American National Dictionary for Information Processing Systems}.)}
-\begin{example} This International Standard permits two's complement,
+\begin{example} This document permits two's complement,
 ones' complement and signed magnitude representations for integral types.
 \end{example}
 
@@ -3897,7 +3897,7 @@
 floating-point types}.
 \indextext{floating-point type!implementation-defined}%
 \begin{note}
-This International Standard imposes no requirements on the accuracy of
+This document imposes no requirements on the accuracy of
 floating-point operations; see also~\ref{support.limits}.
 \end{note}
 Integral and floating types are collectively
@@ -4158,7 +4158,7 @@
 \end{floattable}
 
 \pnum
-In this International Standard, the notation \cv{} (or
+In this document, the notation \cv{} (or
 \cvqual{cv1}, \cvqual{cv2}, etc.), used in the description of types,
 represents an arbitrary set of cv-qualifiers, i.e., one of
 \{\tcode{const}\}, \{\tcode{volatile}\}, \{\tcode{const},

source/compatibility.tex

@@ -191,7 +191,7 @@
 Those problems not found by typesafe linkage will continue to
 function properly,
 according to the ``layout compatibility rules'' of this
-International Standard.
+document.
 \howwide
 Common.
 
@@ -1075,8 +1075,8 @@
 \change Additional restrictions on macro names.
 \rationale Avoid hard to diagnose or non-portable constructs.
 \effect
-Names of attribute identifiers may not be used as macro names. Valid \Cpp
-2003 code that defines \tcode{override}, \tcode{final},
+Names of attribute identifiers may not be used as macro names. Valid \CppIII
+code that defines \tcode{override}, \tcode{final},
 \tcode{carries_dependency}, or \tcode{noreturn} as macros is invalid in this
 International Standard.
 

source/declarations.tex

@@ -3378,7 +3378,7 @@
 \end{bnf}
 
 The \grammarterm{string-literal} indicates the required language linkage.
-This International Standard specifies the semantics for the
+This document specifies the semantics for the
 \grammarterm{string-literal}{s} \tcode{"C"} and \tcode{"C++"}. Use of a
 \grammarterm{string-literal} other than \tcode{"C"} or \tcode{"C++"} is
 conditionally-supported, with \impldef{semantics of linkage specifiers} semantics.
@@ -3722,7 +3722,7 @@
 \pnum
 For an \grammarterm{attribute-token}
 (including an \grammarterm{attribute-scoped-token})
-not specified in this International Standard, the
+not specified in this document, the
 behavior is \impldef{behavior of non-standard attributes}.
 Any \grammarterm{attribute-token} that is not recognized by the implementation
 is ignored.

source/diagnostics.tex

@@ -937,8 +937,7 @@
 The class \tcode{error_category} serves as a base class for types used
 to identify the source and encoding of a particular category of error code.
 Classes may be derived from \tcode{error_category} to support
-categories of errors in addition to those defined in this International
-Standard.
+categories of errors in addition to those defined in this document.
 Such classes shall behave as specified in this
 subclause. \begin{note} \tcode{error_category} objects are
 passed by reference, and two such objects

source/expressions.tex

@@ -4972,7 +4972,7 @@
 \item
 an operation that would have undefined behavior
 as specified in Clauses~\ref{intro} through~\ref{cpp}
-of this International Standard \begin{note} including,
+of this document \begin{note} including,
 for example, signed integer overflow~(Clause \ref{expr}), certain
 pointer arithmetic~(\ref{expr.add}), division by
 zero~(\ref{expr.mul}), or certain shift operations~(\ref{expr.shift})
@@ -5108,7 +5108,7 @@
 If \tcode{e} satisfies the constraints of a core constant expression, but
 evaluation of \tcode{e} would evaluate an operation that has undefined behavior
 as specified in Clauses~\ref{library} through~\ref{\lastlibchapter} of this
-International Standard, it is unspecified whether \tcode{e} is a core constant
+document, it is unspecified whether \tcode{e} is a core constant
 expression.
 
 \begin{example}
@@ -5231,7 +5231,7 @@
 function.
 
 \pnum
-\begin{note} Since this International Standard
+\begin{note} Since this document
 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

source/future.tex

@@ -1307,7 +1307,7 @@
 \pnum
 To enable old function adaptors to manipulate function objects
 that take one or two arguments,
-many of the function objects in this International Standard
+many of the function objects in this document
 correspondingly provide \grammarterm{typedef-name}{s}
 \tcode{argument_type} and \tcode{result_type}
 for function objects that take one argument and

source/intro.tex

@@ -267,12 +267,12 @@
 
 \indexdefn{behavior!undefined}%
 \definition{undefined behavior}{defns.undefined}
-behavior for which this International Standard
+behavior for which this document
 imposes no requirements
 
 \begin{defnote}
 Undefined behavior may be expected when
-this International Standard omits any explicit
+this document omits any explicit
 definition of behavior or when a program uses an erroneous construct or erroneous data.
 Permissible undefined behavior ranges
 from ignoring the situation completely with unpredictable results, to
@@ -293,7 +293,7 @@
 \begin{defnote}
 The implementation is not required to
 document which behavior occurs. The range of
-possible behaviors is usually delineated by this International Standard.
+possible behaviors is usually delineated by this document.
 \end{defnote}
 
 \indexdefn{program!well-formed}%
@@ -333,34 +333,34 @@
 \indextext{conformance requirements!general|(}%
 The set of
 \defn{diagnosable rules}
-consists of all syntactic and semantic rules in this International
-Standard except for those rules containing an explicit notation that
+consists of all syntactic and semantic rules in this document
+except for those rules containing an explicit notation that
 ``no diagnostic is required'' or which are described as resulting in
 ``undefined behavior''.
 
 \pnum
 \indextext{conformance requirements!method of description}%
-Although this International Standard states only requirements on \Cpp
+Although this document states only requirements on \Cpp
 implementations, those requirements are often easier to understand if
 they are phrased as requirements on programs, parts of programs, or
 execution of programs. Such requirements have the following meaning:
 \begin{itemize}
 \item
 If a program contains no violations of the rules in this
-International Standard, a conforming implementation shall,
+document, a conforming implementation shall,
 within its resource limits, accept and correctly execute\footnote{``Correct execution'' can include undefined behavior, depending on
 the data being processed; see Clause~\ref{intro.defs} and~\ref{intro.execution}.}
 that program.
 \item
 \indextext{message!diagnostic}%
 If a program contains a violation of any diagnosable rule or an occurrence
-of a construct described in this International Standard as ``conditionally-supported'' when
+of a construct described in this document as ``conditionally-supported'' when
 the implementation does not support that construct, a conforming implementation
 shall issue at least one diagnostic message.
 \item
 \indextext{behavior!undefined}%
 If a program contains a violation of a rule for which no diagnostic
-is required, this International Standard places no requirement on
+is required, this document places no requirement on
 implementations with respect to that program.
 \end{itemize}
 \begin{note}
@@ -400,7 +400,7 @@
 \pnum
 Two kinds of implementations are defined: a \defn{hosted implementation} and a
 \defn{freestanding implementation}. For a hosted implementation, this
-International Standard defines the set of available libraries. A freestanding
+document defines the set of available libraries. A freestanding
 implementation is one in which execution may take place without the benefit of
 an operating system, and has an \impldef{required libraries for freestanding
 implementation} set of libraries that includes certain language-support
@@ -411,7 +411,7 @@
 additional library functions), provided they do not alter the
 behavior of any well-formed program.
 Implementations are required to diagnose programs that use such
-extensions that are ill-formed according to this International Standard.
+extensions that are ill-formed according to this document.
 Having done so, however, they can compile and execute such programs.
 
 \pnum
@@ -756,17 +756,17 @@
 \pnum
 \indextext{program execution|(}%
 \indextext{program execution!abstract machine}%
-The semantic descriptions in this International Standard define a
-parameterized nondeterministic abstract machine. This International
-Standard places no requirement on the structure of conforming
+The semantic descriptions in this document define a
+parameterized nondeterministic abstract machine. This document
+places no requirement on the structure of conforming
 implementations. In particular, they need not copy or emulate the
 structure of the abstract machine.
 \indextext{as-if rule}%
 \indextext{behavior!observable}%
 Rather, conforming implementations are required to emulate (only) the observable
 behavior of the abstract machine as explained below.\footnote{This provision is
 sometimes called the ``as-if'' rule, because an implementation is free to
-disregard any requirement of this International Standard as long as the result
+disregard any requirement of this document as long as the result
 is \emph{as if} the requirement had been obeyed, as far as can be determined
 from the observable behavior of the program. For instance, an actual
 implementation need not evaluate part of an expression if it can deduce that its
@@ -778,7 +778,7 @@
 \indextext{behavior!implementation-defined}%
 \pnum
 Certain aspects and operations of the abstract machine are described in this
-International Standard as implementation-defined (for example,
+document as implementation-defined (for example,
 \tcode{sizeof(int)}). These constitute the parameters of the abstract machine.
 Each implementation shall include documentation describing its characteristics
 and behavior in these respects.\footnote{This documentation also includes
@@ -790,20 +790,20 @@
 \indextext{behavior!unspecified}%
 \pnum
 Certain other aspects and operations of the abstract machine are
-described in this International Standard as unspecified (for example,
+described in this document as unspecified (for example,
 evaluation of expressions in a \grammarterm{new-initializer} if the allocation
 function fails to allocate memory~(\ref{expr.new})). Where possible, this
-International Standard defines a set of allowable behaviors. These
+document defines a set of allowable behaviors. These
 define the nondeterministic aspects of the abstract machine. An instance
 of the abstract machine can thus have more than one possible execution
 for a given program and a given input.
 
 \indextext{behavior!undefined}%
 \pnum
-Certain other operations are described in this International Standard as
+Certain other operations are described in this document as
 undefined (for example, the effect of
 attempting to modify a \tcode{const} object).
-\begin{note} This International Standard imposes no requirements on the
+\begin{note} This document imposes no requirements on the
 behavior of programs that contain undefined behavior. \end{note}
 
 \indextext{program!well-formed}%
@@ -814,7 +814,7 @@
 of the corresponding instance of the abstract machine with the
 same program and the same input.
 \indextext{behavior!undefined}%
-However, if any such execution contains an undefined operation, this International Standard places no
+However, if any such execution contains an undefined operation, this document places no
 requirement on the implementation executing that program with that input
 (not even with regard to operations preceding the first undefined
 operation).
@@ -1160,7 +1160,7 @@
 through a pointer or reference~(\ref{basic.compound}).} Under a hosted
 implementation, a \Cpp program can have more than one thread running
 concurrently. The execution of each thread proceeds as defined by the remainder
-of this International Standard. The execution of the entire program consists of an execution
+of this document. The execution of the entire program consists of an execution
 of all of its threads. \begin{note} Usually the execution can be viewed as an
 interleaving of all its threads. However, some kinds of atomic operations, for
 example, allow executions inconsistent with a simple interleaving, as described
@@ -1490,7 +1490,7 @@
 \pnum
 \begin{note} Compiler transformations that introduce assignments to a potentially
 shared memory location that would not be modified by the abstract machine are
-generally precluded by this International Standard, since such an assignment might overwrite
+generally precluded by this document, since such an assignment might overwrite
 another assignment by a different thread in cases in which an abstract machine
 execution would not have encountered a data race. This includes implementations
 of data member assignment that overwrite adjacent members in separate memory
@@ -1501,7 +1501,7 @@
 \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
-defined in this International Standard, since they potentially introduce a data race. However,
+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
 invalid for a hypothetical machine that is not tolerant of races or provides

source/iterators.tex

@@ -72,7 +72,7 @@
 function template
 that takes iterators
 works as well with regular pointers.
-This International Standard defines
+This document defines
 five categories of iterators, according to the operations
 defined on them:
 \techterm{input iterators},

source/lex.tex

@@ -29,8 +29,8 @@
 \indextext{conventions!lexical|(}%
 \indextext{compilation!separate|(}%
 The text of the program is kept in units called
-\defnx{source files}{source file} in this International
-Standard. A source file together with all the headers~(\ref{headers})
+\defnx{source files}{source file} in this document.
+A source file together with all the headers~(\ref{headers})
 and source files included~(\ref{cpp.include}) via the preprocessing
 directive \tcode{\#include}, less any source lines skipped by any of the
 conditional inclusion~(\ref{cpp.cond}) preprocessing directives, is
@@ -817,7 +817,7 @@
 \indextext{constant}%
 \indextext{literal!constant}%
 There are several kinds of literals.\footnote{The term ``literal'' generally designates, in this
-International Standard, those tokens that are called ``constants'' in
+document, those tokens that are called ``constants'' in
 ISO C. }
 
 \begin{bnf}