[except] - C++11 → C++14

Files changed (1) hide show

tmp/tmptkgpth1u/{from.md → to.md} +137 -96

tmp/tmptkgpth1u/{from.md → to.md} RENAMED Viewed

@@ -1,13 +1,13 @@
 # Exception handling <a id="except">[[except]]</a>
 Exception handling provides a way of transferring control and
 information from a point in the execution of a thread to an exception
 handler associated with a point previously passed by the execution. A
-handler will be invoked only by a *throw-expression* invoked in code
-executed in the handler’s try block or in functions called from the
-handler’s try block .
 ``` bnf
 try-block:
     'try' compound-statement handler-seq
 ```
@@ -38,18 +38,15 @@ exception-declaration:
 throw-expression:
     'throw' assignment-expressionₒₚₜ
 ```
 The optional *attribute-specifier-seq* in an *exception-declaration*
-appertains to the formal parameter of the catch clause (
-[[except.handle]]).
 A *try-block* is a *statement* (Clause  [[stmt.stmt]]). A
-*throw-expression* is of type `void`. Code that executes a
-*throw-expression* is said to “throw an exception;” code that
-subsequently gets control is called a “handler.” Within this Clause “try
-block” is taken to mean both *try-block* and *function-try-block*.
 A `goto` or `switch` statement shall not be used to transfer control
 into a try block or into a handler.
 ``` cpp
@@ -117,13 +114,17 @@ catch (...) {
 }
 ```
 ## Throwing an exception <a id="except.throw">[[except.throw]]</a>
-Throwing an exception transfers control to a handler. An object is
-passed and the type of that object determines which handlers can catch
-it.
 ``` cpp
 throw "Help!";
 ```
@@ -165,23 +166,21 @@ When an exception is thrown, control is transferred to the nearest
 handler with a matching type ([[except.handle]]); “nearest” means the
 handler for which the *compound-statement* or *ctor-initializer*
 following the `try` keyword was most recently entered by the thread of
 control and not yet exited.
-A *throw-expression* initializes a temporary object, called the
-*exception object*, the type of which is determined by removing any
-top-level *cv-qualifier*s from the static type of the operand of `throw`
-and adjusting the type from “array of `T`” or “function returning `T`”
-to “pointer to `T`” or “pointer to function returning `T`”,
-respectively. The temporary is an lvalue and is used to initialize the
-variable named in the matching *handler* ([[except.handle]]). If the
-type of the exception object would be an incomplete type or a pointer to
-an incomplete type other than (possibly cv-qualified) `void` the program
-is ill-formed. Except for these restrictions and the restrictions on
-type matching mentioned in  [[except.handle]], the operand of `throw` is
-treated exactly as a function argument in a call ([[expr.call]]) or the
-operand of a return statement.
 The memory for the exception object is allocated in an unspecified way,
 except as noted in  [[basic.stc.dynamic.allocation]]. If a handler exits
 by rethrowing, control is passed to another handler for the same
 exception. The exception object is destroyed after either the last
@@ -192,43 +191,48 @@ whichever is later. In the former case, the destruction occurs when the
 handler exits, immediately after the destruction of the object declared
 in the *exception-declaration* in the handler, if any. In the latter
 case, the destruction occurs before the destructor of
 `std::exception_ptr` returns. The implementation may then deallocate the
 memory for the exception object; any such deallocation is done in an
-unspecified way. an exception thrown by a *throw-expression* does not
-propagate to other threads unless caught, stored, and rethrown using
-appropriate library functions; see  [[propagation]] and  [[futures]].
-When the thrown object is a class object, the copy/move constructor and
-the destructor shall be accessible, even if the copy/move operation is
-elided ([[class.copy]]).
 An exception is considered caught when a handler for that exception
 becomes active ([[except.handle]]). An exception can have active
 handlers and still be considered uncaught if it is rethrown.
-If the exception handling mechanism, after completing evaluation of the
-expression to be thrown but before the exception is caught, calls a
-function that exits via an exception, `std::terminate` is called (
-[[except.terminate]]).
 ``` cpp
 struct C {
   C() { }
-  C(const C&) { throw 0; }
 };
 int main() {
   try {
-    throw C();      // calls std::terminate()
   } catch(C) { }
 }
 ```
 A *throw-expression* with no operand rethrows the currently handled
 exception ([[except.handle]]). The exception is reactivated with the
-existing temporary; no new temporary exception object is created. The
 exception is no longer considered to be caught; therefore, the value of
 `std::uncaught_exception()` will again be `true`. code that must be
 executed because of an exception yet cannot completely handle the
 exception can be written like this:
@@ -246,14 +250,14 @@ If no exception is presently being handled, executing a
 *throw-expression* with no operand calls `std::terminate()` (
 [[except.terminate]]).
 ## Constructors and destructors <a id="except.ctor">[[except.ctor]]</a>
-As control passes from a *throw-expression* to a handler, destructors
-are invoked for all automatic objects constructed since the try block
-was entered. The automatic objects are destroyed in the reverse order of
-the completion of their construction.
 An object of any storage duration whose initialization or destruction is
 terminated by an exception will have destructors executed for all of its
 fully constructed subobjects (excluding the variant members of a
 union-like class), that is, for subobjects for which the principal
@@ -265,15 +269,15 @@ destructor will be invoked. If the object was allocated in a
 *new-expression*, the matching deallocation function (
 [[basic.stc.dynamic.deallocation]], [[expr.new]], [[class.free]]), if
 any, is called to free the storage occupied by the object.
 The process of calling destructors for automatic objects constructed on
-the path from a try block to a *throw-expression* is called “*stack
-unwinding*.” If a destructor called during stack unwinding exits with an
-exception, `std::terminate` is called ([[except.terminate]]). So
-destructors should generally catch exceptions and not let them propagate
-out of the destructor.
 ## Handling an exception <a id="except.handle">[[except.handle]]</a>
 The *exception-declaration* in a *handler* describes the type(s) of
 exceptions that can cause that *handler* to be entered. The
@@ -291,22 +295,21 @@ A *handler* is a match for an exception object of type `E` if
 - The *handler* is of type *cv* `T` or *cv* `T&` and `E` and `T` are the
   same type (ignoring the top-level *cv-qualifiers*), or
 - the *handler* is of type *cv* `T` or *cv* `T&` and `T` is an
   unambiguous public base class of `E`, or
-- the *handler* is of type *cv1* `T*` *cv2* and `E` is a pointer type
- that can be converted to the type of the *handler* by either or both
-  of
   - a standard pointer conversion ([[conv.ptr]]) not involving
     conversions to pointers to private or protected or ambiguous classes
-  - a qualification conversion
-- the *handler* is a pointer or pointer to member type and `E` is
-  `std::nullptr_t`.
-A *throw-expression* whose operand is an integral constant expression of
-integer type that evaluates to zero does not match a handler of pointer
-or pointer to member type.
 ``` cpp
 class Matherr { /* ... */ virtual void vf(); };
 class Overflow: public Matherr { /* ... */ };
 class Underflow: public Matherr { /* ... */ };
@@ -341,16 +344,15 @@ try block.
 If no match is found among the handlers for a try block, the search for
 a matching handler continues in a dynamically surrounding try block of
 the same thread.
 A handler is considered active when initialization is complete for the
-formal parameter (if any) of the catch clause. The stack will have been
-unwound at that point. Also, an implicit handler is considered active
-when `std::terminate()` or `std::unexpected()` is entered due to a
-throw. A handler is no longer considered active when the catch clause
-exits or when `std::unexpected()` exits after being entered due to a
-throw.
 The exception with the most recently activated handler that is still
 active is called the *currently handled exception*.
 If no matching handler is found, the function `std::terminate()` is
@@ -391,25 +393,27 @@ Otherwise, a function returns when control reaches the end of a handler
 for the *function-try-block* ([[stmt.return]]). Flowing off the end of
 a *function-try-block* is equivalent to a `return` with no value; this
 results in undefined behavior in a value-returning function (
 [[stmt.return]]).
-If the *exception-declaration* specifies a name, it declares a variable
-which is copy-initialized ([[dcl.init]]) from the exception object. If
-the *exception-declaration* denotes an object type but does not specify
-a name, a temporary ([[class.temporary]]) is copy-initialized (
-[[dcl.init]]) from the exception object. The lifetime of the variable or
-temporary ends when the handler exits, after the destruction of any
-automatic objects initialized within the handler.
-When the handler declares a non-constant object, any changes to that
-object will not affect the temporary object that was initialized by
-execution of the *throw-expression*. When the handler declares a
-reference to a non-constant object, any changes to the referenced object
-are changes to the temporary object initialized when the
-*throw-expression* was executed and will have effect should that object
-be rethrown.
 ## Exception specifications <a id="except.spec">[[except.spec]]</a>
 A function declaration lists exceptions that its function might directly
 or indirectly throw by using an *exception-specification* as a suffix of
@@ -439,11 +443,13 @@ noexcept-specification:
 ```
 In a *noexcept-specification*, the *constant-expression*, if supplied,
 shall be a constant expression ([[expr.const]]) that is contextually
 converted to `bool` (Clause  [[conv]]). A *noexcept-specification*
-`noexcept` is equivalent to `noexcept({}true)`.
 An *exception-specification* shall appear only on a function declarator
 for a function type, pointer to function type, reference to function
 type, or pointer to member function type that is the top-level type of a
 declaration or definition, or on such a type appearing as a parameter or
@@ -456,16 +462,16 @@ void (*fp)() throw (int);               // OK
 void g(void pfa() throw(int));          // OK
 typedef int (*pf)() throw(int);         // ill-formed
 ```
 A type denoted in an *exception-specification* shall not denote an
-incomplete type. A type denoted in an *exception-specification* shall
-not denote a pointer or reference to an incomplete type, other than
-`void*`, `const` `void*`, `volatile` `void*`, or `const` `volatile`
-`void*`. A type cv `T`, “array of `T`”, or “function returning `T`”
-denoted in an *exception-specification* is adjusted to type `T`,
-“pointer to `T`”, or “pointer to function returning `T`”, respectively.
 Two *exception-specification*s are *compatible* if:
 - both are non-throwing (see below), regardless of their form,
 - both have the form `noexcept(`*constant-expression*`)` and the
@@ -599,37 +605,42 @@ yields `true`. A function with a non-throwing *exception-specification*
 does not allow any exceptions.
 An *exception-specification* is not considered part of a function’s
 type.
-An implicitly declared special member function (Clause  [[special]])
-shall have an *exception-specification*. If `f` is an implicitly
-declared default constructor, copy constructor, move constructor,
-destructor, copy assignment operator, or move assignment operator, its
-implicit *exception-specification* specifies the *type-id* `T` if and
-only if `T` is allowed by the *exception-specification* of a function
-directly invoked by `f`’s implicit definition; `f` shall allow all
 exceptions if any function it directly invokes allows all exceptions,
-and `f` shall allow no exceptions if every function it directly invokes
-allows no exceptions.
 ``` cpp
 struct A {
   A();
   A(const A&) throw();
   A(A&&) throw();
   ~A() throw(X);
 };
 struct B {
   B() throw();
-  B(const B&) throw();
   B(B&&) throw(Y);
   ~B() throw(Y);
 };
 struct D : public A, public B {
     // Implicit declaration of D::D();
-    // Implicit declaration of D::D(const D&) throw();
     // Implicit declaration of D::D(D&&) throw(Y);
     // Implicit declaration of D::~D() throw(X, Y);
 };
 ```
@@ -641,10 +652,34 @@ restrictive as that in the base class.
 A deallocation function ([[basic.stc.dynamic.deallocation]]) with no
 explicit *exception-specification* is treated as if it were specified
 with `noexcept(true)`.
 In a *dynamic-exception-specification*, a *type-id* followed by an
 ellipsis is a pack expansion ([[temp.variadic]]).
 The use of *dynamic-exception-specification*s is deprecated (see Annex
 [[depr]]).
@@ -754,19 +789,21 @@ exception is rethrown ([[except.throw]]), `std::uncaught_exception()`
 returns `true` from the point of rethrow until the rethrown exception is
 caught again.
 <!-- Link reference definitions -->
 [bad.exception]: language.md#bad.exception
 [basic.start.init]: basic.md#basic.start.init
 [basic.start.term]: basic.md#basic.start.term
 [basic.stc.dynamic.allocation]: basic.md#basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: basic.md#basic.stc.dynamic.deallocation
 [class.base.init]: special.md#class.base.init
 [class.copy]: special.md#class.copy
 [class.dtor]: special.md#class.dtor
 [class.free]: special.md#class.free
-[class.temporary]: special.md#class.temporary
 [conv]: conv.md#conv
 [conv.ptr]: conv.md#conv.ptr
 [dcl.init]: dcl.md#dcl.init
 [depr]: future.md#depr
 [except]: #except
@@ -779,19 +816,23 @@ caught again.
 [except.throw]: #except.throw
 [except.uncaught]: #except.uncaught
 [except.unexpected]: #except.unexpected
 [exception.terminate]: language.md#exception.terminate
 [exception.unexpected]: future.md#exception.unexpected
-[expr.call]: expr.md#expr.call
 [expr.const]: expr.md#expr.const
 [expr.new]: expr.md#expr.new
 [futures]: thread.md#futures
 [propagation]: language.md#propagation
 [set.unexpected]: future.md#set.unexpected
 [special]: special.md#special
 [stmt.return]: stmt.md#stmt.return
 [stmt.stmt]: stmt.md#stmt.stmt
 [support.start.term]: language.md#support.start.term
 [temp.variadic]: temp.md#temp.variadic
 [thread.thread.assign]: thread.md#thread.thread.assign
 [thread.thread.constr]: thread.md#thread.thread.constr
 [thread.thread.destr]: thread.md#thread.thread.destr

 # Exception handling <a id="except">[[except]]</a>
 Exception handling provides a way of transferring control and
 information from a point in the execution of a thread to an exception
 handler associated with a point previously passed by the execution. A
+handler will be invoked only by throwing an exception in code executed
+in the handler’s try block or in functions called from the handler’s try
+block.
 ``` bnf
 try-block:
     'try' compound-statement handler-seq
 ```
 throw-expression:
     'throw' assignment-expressionₒₚₜ
 ```
 The optional *attribute-specifier-seq* in an *exception-declaration*
+appertains to the parameter of the catch clause ([[except.handle]]).
 A *try-block* is a *statement* (Clause  [[stmt.stmt]]). A
+*throw-expression* is of type `void`. Within this Clause “try block” is
+taken to mean both *try-block* and *function-try-block*.
 A `goto` or `switch` statement shall not be used to transfer control
 into a try block or into a handler.
 ``` cpp
 }
 ```
 ## Throwing an exception <a id="except.throw">[[except.throw]]</a>
+Throwing an exception transfers control to a handler. An exception can
+be thrown from one of the following contexts: *throw-expression* (see
+below), allocation functions ([[basic.stc.dynamic.allocation]]),
+`dynamic_cast` ([[expr.dynamic.cast]]), `typeid` ([[expr.typeid]]),
+*new-expression* ([[expr.new]]), and standard library functions (
+[[structure.specifications]]). An object is passed and the type of that
+object determines which handlers can catch it.
 ``` cpp
 throw "Help!";
 ```
 handler with a matching type ([[except.handle]]); “nearest” means the
 handler for which the *compound-statement* or *ctor-initializer*
 following the `try` keyword was most recently entered by the thread of
 control and not yet exited.
+Throwing an exception copy-initializes ([[dcl.init]], [[class.copy]]) a
+temporary object, called the *exception object*. The temporary is an
+lvalue and is used to initialize the variable declared in the matching
+*handler* ([[except.handle]]). If the type of the exception object
+would be an incomplete type or a pointer to an incomplete type other
+than (possibly cv-qualified) `void` the program is ill-formed.
+Evaluating a *throw-expression* with an operand throws an exception; the
+type of the exception object is determined by removing any top-level
+*cv-qualifiers* from the static type of the operand and adjusting the
+type from “array of `T`” or “function returning `T`” to “pointer to `T`”
+or “pointer to function returning `T`,” respectively.
 The memory for the exception object is allocated in an unspecified way,
 except as noted in  [[basic.stc.dynamic.allocation]]. If a handler exits
 by rethrowing, control is passed to another handler for the same
 exception. The exception object is destroyed after either the last
 handler exits, immediately after the destruction of the object declared
 in the *exception-declaration* in the handler, if any. In the latter
 case, the destruction occurs before the destructor of
 `std::exception_ptr` returns. The implementation may then deallocate the
 memory for the exception object; any such deallocation is done in an
+unspecified way. a thrown exception does not propagate to other threads
+unless caught, stored, and rethrown using appropriate library functions;
+see  [[propagation]] and  [[futures]].
+When the thrown object is a class object, the constructor selected for
+the copy-initialization and the destructor shall be accessible, even if
+the copy/move operation is elided ([[class.copy]]).
 An exception is considered caught when a handler for that exception
 becomes active ([[except.handle]]). An exception can have active
 handlers and still be considered uncaught if it is rethrown.
+If the exception handling mechanism, after completing the initialization
+of the exception object but before the activation of a handler for the
+exception, calls a function that exits via an exception,
+`std::terminate` is called ([[except.terminate]]).
 ``` cpp
 struct C {
   C() { }
+  C(const C&) {
+    if (std::uncaught_exception()) {
+      throw 0;      // throw during copy to handler's exception-declaration object~([except.handle])
+    }
+  }
 };
 int main() {
   try {
+    throw C();      // calls std::terminate() if construction of the handler's
+                    // exception-declaration object is not elided~([class.copy])
   } catch(C) { }
 }
 ```
 A *throw-expression* with no operand rethrows the currently handled
 exception ([[except.handle]]). The exception is reactivated with the
+existing exception object; no new exception object is created. The
 exception is no longer considered to be caught; therefore, the value of
 `std::uncaught_exception()` will again be `true`. code that must be
 executed because of an exception yet cannot completely handle the
 exception can be written like this:
 *throw-expression* with no operand calls `std::terminate()` (
 [[except.terminate]]).
 ## Constructors and destructors <a id="except.ctor">[[except.ctor]]</a>
+As control passes from the point where an exception is thrown to a
+handler, destructors are invoked for all automatic objects constructed
+since the try block was entered. The automatic objects are destroyed in
+the reverse order of the completion of their construction.
 An object of any storage duration whose initialization or destruction is
 terminated by an exception will have destructors executed for all of its
 fully constructed subobjects (excluding the variant members of a
 union-like class), that is, for subobjects for which the principal
 *new-expression*, the matching deallocation function (
 [[basic.stc.dynamic.deallocation]], [[expr.new]], [[class.free]]), if
 any, is called to free the storage occupied by the object.
 The process of calling destructors for automatic objects constructed on
+the path from a try block to the point where an exception is thrown is
+called “*stack unwinding*.” If a destructor called during stack
+unwinding exits with an exception, `std::terminate` is called (
+[[except.terminate]]). So destructors should generally catch exceptions
+and not let them propagate out of the destructor.
 ## Handling an exception <a id="except.handle">[[except.handle]]</a>
 The *exception-declaration* in a *handler* describes the type(s) of
 exceptions that can cause that *handler* to be entered. The
 - The *handler* is of type *cv* `T` or *cv* `T&` and `E` and `T` are the
   same type (ignoring the top-level *cv-qualifiers*), or
 - the *handler* is of type *cv* `T` or *cv* `T&` and `T` is an
   unambiguous public base class of `E`, or
+- the *handler* is of type *cv* `T` or `const T&` where `T` is a pointer
+ type and `E` is a pointer type that can be converted to `T` by either
+ or both of
   - a standard pointer conversion ([[conv.ptr]]) not involving
     conversions to pointers to private or protected or ambiguous classes
+  - a qualification conversion, or
+- the *handler* is of type *cv* `T` or `const T&` where `T` is a pointer
+ or pointer to member type and `E` is `std::nullptr_t`.
+A *throw-expression* whose operand is an integer literal with value zero
+does not match a handler of pointer or pointer to member type.
 ``` cpp
 class Matherr { /* ... */ virtual void vf(); };
 class Overflow: public Matherr { /* ... */ };
 class Underflow: public Matherr { /* ... */ };
 If no match is found among the handlers for a try block, the search for
 a matching handler continues in a dynamically surrounding try block of
 the same thread.
 A handler is considered active when initialization is complete for the
+parameter (if any) of the catch clause. The stack will have been unwound
+at that point. Also, an implicit handler is considered active when
+`std::terminate()` or `std::unexpected()` is entered due to a throw. A
+handler is no longer considered active when the catch clause exits or
+when `std::unexpected()` exits after being entered due to a throw.
 The exception with the most recently activated handler that is still
 active is called the *currently handled exception*.
 If no matching handler is found, the function `std::terminate()` is
 for the *function-try-block* ([[stmt.return]]). Flowing off the end of
 a *function-try-block* is equivalent to a `return` with no value; this
 results in undefined behavior in a value-returning function (
 [[stmt.return]]).
+The variable declared by the *exception-declaration*, of type cv `T` or
+cv `T&`, is initialized from the exception object, of type `E`, as
+follows:
+- if `T` is a base class of `E`, the variable is copy-initialized (
+  [[dcl.init]]) from the corresponding base class subobject of the
+  exception object;
+- otherwise, the variable is copy-initialized ([[dcl.init]]) from the
+  exception object.
+The lifetime of the variable ends when the handler exits, after the
+destruction of any automatic objects initialized within the handler.
+When the handler declares an object, any changes to that object will not
+affect the exception object. When the handler declares a reference to an
+object, any changes to the referenced object are changes to the
+exception object and will have effect should that object be rethrown.
 ## Exception specifications <a id="except.spec">[[except.spec]]</a>
 A function declaration lists exceptions that its function might directly
 or indirectly throw by using an *exception-specification* as a suffix of
 ```
 In a *noexcept-specification*, the *constant-expression*, if supplied,
 shall be a constant expression ([[expr.const]]) that is contextually
 converted to `bool` (Clause  [[conv]]). A *noexcept-specification*
+`noexcept` is equivalent to `noexcept(true)`. A `(` token that follows
+`noexcept` is part of the *noexcept-specification* and does not commence
+an initializer ([[dcl.init]]).
 An *exception-specification* shall appear only on a function declarator
 for a function type, pointer to function type, reference to function
 type, or pointer to member function type that is the top-level type of a
 declaration or definition, or on such a type appearing as a parameter or
 void g(void pfa() throw(int));          // OK
 typedef int (*pf)() throw(int);         // ill-formed
 ```
 A type denoted in an *exception-specification* shall not denote an
+incomplete type or an rvalue reference type. A type denoted in an
+*exception-specification* shall not denote a pointer or reference to an
+incomplete type, other than *cv* `void*`. A type cv `T`, “array of `T`”,
+or “function returning `T`” denoted in an *exception-specification* is
+adjusted to type `T`, “pointer to `T`”, or “pointer to function
+returning `T`”, respectively.
 Two *exception-specification*s are *compatible* if:
 - both are non-throwing (see below), regardless of their form,
 - both have the form `noexcept(`*constant-expression*`)` and the
 does not allow any exceptions.
 An *exception-specification* is not considered part of a function’s
 type.
+An inheriting constructor ([[class.inhctor]]) and an implicitly
+declared special member function (Clause  [[special]]) have an
+*exception-specification*. If `f` is an inheriting constructor or an
+implicitly declared default constructor, copy constructor, move
+constructor, destructor, copy assignment operator, or move assignment
+operator, its implicit *exception-specification* specifies the *type-id*
+`T` if and only if `T` is allowed by the *exception-specification* of a
+function directly invoked by `f`’s implicit definition; `f` allows all
 exceptions if any function it directly invokes allows all exceptions,
+and `f` has the *exception-specification* `noexcept(true)` if every
+function it directly invokes allows no exceptions. It follows that `f`
+has the *exception-specification* `noexcept(true)` if it invokes no
+other functions. An instantiation of an inheriting constructor template
+has an implied *exception-specification* as if it were a non-template
+inheriting constructor.
 ``` cpp
 struct A {
   A();
   A(const A&) throw();
   A(A&&) throw();
   ~A() throw(X);
 };
 struct B {
   B() throw();
+  B(const B&) = default; // Declaration of B::B(const B&) noexcept(true)
   B(B&&) throw(Y);
   ~B() throw(Y);
 };
 struct D : public A, public B {
     // Implicit declaration of D::D();
+    // Implicit declaration of D::D(const D&) noexcept(true);
     // Implicit declaration of D::D(D&&) throw(Y);
     // Implicit declaration of D::~D() throw(X, Y);
 };
 ```
 A deallocation function ([[basic.stc.dynamic.deallocation]]) with no
 explicit *exception-specification* is treated as if it were specified
 with `noexcept(true)`.
+An *exception-specification* is considered to be *needed* when:
+- in an expression, the function is the unique lookup result or the
+  selected member of a set of overloaded functions ([[basic.lookup]],
+  [[over.match]], [[over.over]]);
+- the function is odr-used ([[basic.def.odr]]) or, if it appears in an
+  unevaluated operand, would be odr-used if the expression were
+  potentially-evaluated;
+- the *exception-specification* is compared to that of another
+  declaration (e.g., an explicit specialization or an overriding virtual
+  function);
+- the function is defined; or
+- the *exception-specification* is needed for a defaulted special member
+  function that calls the function. A defaulted declaration does not
+  require the *exception-specification* of a base member function to be
+  evaluated until the implicit *exception-specification* of the derived
+  function is needed, but an explicit *exception-specification* needs
+  the implicit *exception-specification* to compare against.
+The *exception-specification* of a defaulted special member function is
+evaluated as described above only when needed; similarly, the
+*exception-specification* of a specialization of a function template or
+member function of a class template is instantiated only when needed.
 In a *dynamic-exception-specification*, a *type-id* followed by an
 ellipsis is a pack expansion ([[temp.variadic]]).
 The use of *dynamic-exception-specification*s is deprecated (see Annex
 [[depr]]).
 returns `true` from the point of rethrow until the rethrown exception is
 caught again.
 <!-- Link reference definitions -->
 [bad.exception]: language.md#bad.exception
+[basic.def.odr]: basic.md#basic.def.odr
+[basic.lookup]: basic.md#basic.lookup
 [basic.start.init]: basic.md#basic.start.init
 [basic.start.term]: basic.md#basic.start.term
 [basic.stc.dynamic.allocation]: basic.md#basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: basic.md#basic.stc.dynamic.deallocation
 [class.base.init]: special.md#class.base.init
 [class.copy]: special.md#class.copy
 [class.dtor]: special.md#class.dtor
 [class.free]: special.md#class.free
+[class.inhctor]: special.md#class.inhctor
 [conv]: conv.md#conv
 [conv.ptr]: conv.md#conv.ptr
 [dcl.init]: dcl.md#dcl.init
 [depr]: future.md#depr
 [except]: #except
 [except.throw]: #except.throw
 [except.uncaught]: #except.uncaught
 [except.unexpected]: #except.unexpected
 [exception.terminate]: language.md#exception.terminate
 [exception.unexpected]: future.md#exception.unexpected
 [expr.const]: expr.md#expr.const
+[expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.new]: expr.md#expr.new
+[expr.typeid]: expr.md#expr.typeid
 [futures]: thread.md#futures
+[over.match]: over.md#over.match
+[over.over]: over.md#over.over
 [propagation]: language.md#propagation
 [set.unexpected]: future.md#set.unexpected
 [special]: special.md#special
 [stmt.return]: stmt.md#stmt.return
 [stmt.stmt]: stmt.md#stmt.stmt
+[structure.specifications]: library.md#structure.specifications
 [support.start.term]: language.md#support.start.term
 [temp.variadic]: temp.md#temp.variadic
 [thread.thread.assign]: thread.md#thread.thread.assign
 [thread.thread.constr]: thread.md#thread.thread.constr
 [thread.thread.destr]: thread.md#thread.thread.destr

Diff to HTML by rtfpessoa