[except.spec] - C++14 → C++17

Files changed (1) hide show

tmp/tmpmunk95tt/{from.md → to.md} +140 -208

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

@@ -1,271 +1,203 @@
 ## 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
-its declarator.
 ``` bnf
-exception-specification:
-    dynamic-exception-specification
-    noexcept-specification
-```
-``` bnf
-dynamic-exception-specification:
-    'throw (' type-id-listₒₚₜ ')'
-```
-``` bnf
-type-id-list:
-    type-id '...'ₒₚₜ
-    type-id-list ',' type-id '...'ₒₚₜ
-```
-``` bnf
-noexcept-specification:
     'noexcept' '(' constant-expression ')'
     'noexcept'
 ```
-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
-return type in a function declarator. An *exception-specification* shall
-not appear in a typedef declaration or *alias-declaration*.
-``` cpp
-void f() throw(int);                    // OK
-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 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
-  *constant-expression*s are equivalent, or
-- both are *dynamic-exception-specification*s that have the same set of
-  adjusted types.
-If any declaration of a function has an *exception-specification* that
-is not a *noexcept-specification* allowing all exceptions, all
-declarations, including the definition and any explicit specialization,
-of that function shall have a compatible *exception-specification*. If
-any declaration of a pointer to function, reference to function, or
-pointer to member function has an *exception-specification*, all
-occurrences of that declaration shall have a compatible
-*exception-specification* In an explicit instantiation an
-*exception-specification* may be specified, but is not required. If an
-*exception-specification* is specified in an explicit instantiation
-directive, it shall be compatible with the *exception-specification*s of
-other declarations of that function. A diagnostic is required only if
-the *exception-specification*s are not compatible within a single
-translation unit.
-If a virtual function has an *exception-specification*, all
 declarations, including the definition, of any function that overrides
-that virtual function in any derived class shall only allow exceptions
-that are allowed by the *exception-specification* of the base class
-virtual function.
 ``` cpp
 struct B {
-  virtual void f() throw (int, double);
   virtual void g();
 };
 struct D: B {
   void f();                     // ill-formed
-  void g() throw (int); // OK
 };
 ```
-The declaration of `D::f` is ill-formed because it allows all
-exceptions, whereas `B::f` allows only `int` and `double`. A similar
-restriction applies to assignment to and initialization of pointers to
-functions, pointers to member functions, and references to functions:
-the target entity shall allow at least the exceptions allowed by the
-source value in the assignment or initialization.
-``` cpp
-class A { /* ... */ };
-void (*pf1)();      // no exception specification
-void (*pf2)() throw(A);
-void f() {
-  pf1 = pf2;        // OK: pf1 is less restrictive
-  pf2 = pf1;        // error: pf2 is more restrictive
-}
-```
-In such an assignment or initialization, *exception-specification*s on
-return types and parameter types shall be compatible. In other
-assignments or initializations, *exception-specification*s shall be
-compatible.
-An *exception-specification* can include the same type more than once
-and can include classes that are related by inheritance, even though
-doing so is redundant. An *exception-specification* can also include the
-class `std::bad_exception` ([[bad.exception]]).
-A function is said to *allow* an exception of type `E` if the
-*constant-expression* in its *noexcept-specification* evaluates to
-`false` or its *dynamic-exception-specification* contains a type `T` for
-which a handler of type `T` would be a match ([[except.handle]]) for an
-exception of type `E`.
 Whenever an exception is thrown and the search for a handler (
-[[except.handle]]) encounters the outermost block of a function with an
-*exception-specification* that does not allow the exception, then,
-- if the *exception-specification* is a
-  *dynamic-exception-specification*, the function `std::unexpected()` is
-  called ([[except.unexpected]]),
-- otherwise, the function `std::terminate()` is called (
- [[except.terminate]]).
 ``` cpp
-class X { };
-class Y { };
-class Z: public X { };
-class W { };
-void f() throw (X, Y) {
- int n = 0;
- if (n) throw X(); // OK
-  if (n) throw Z();             // also OK
-  throw W();                    // will call std::unexpected()
 }
 ```
-A function can have multiple declarations with different non-throwing
-*exception-specification*s; for this purpose, the one on the function
-definition is used.
-The function `unexpected()` may throw an exception that will satisfy the
-*exception-specification* for which it was invoked, and in this case the
-search for another handler will continue at the call of the function
-with this *exception-specification* (see  [[except.unexpected]]), or it
-may call `std::terminate()`.
-An implementation shall not reject an expression merely because when
-executed it throws or might throw an exception that the containing
-function does not allow.
-``` cpp
-extern void f() throw(X, Y);
-void g() throw(X) {
-  f();                          // OK
-}
-```
-the call to `f` is well-formed even though when called, `f` might throw
-exception `Y` that `g` does not allow.
-A function with no *exception-specification* or with an
-*exception-specification* of the form
-`noexcept(`*constant-expression*`)` where the *constant-expression*
-yields `false` allows all exceptions. An *exception-specification* is
-*non-throwing* if it is of the form `throw()`, `noexcept`, or
-`noexcept(`*constant-expression*`)` where the *constant-expression*
-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 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);
 };
 ```
-Furthermore, if `A::~A()` or `B::~B()` were virtual, `D::~D()` would not
-be as restrictive as that of `A::~A`, and the program would be
-ill-formed since a function that overrides a virtual function from a
-base class shall have an *exception-specification* at least as
-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)`.
-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]]).

 ## Exception specifications <a id="except.spec">[[except.spec]]</a>
+The predicate indicating whether a function cannot exit via an exception
+is called the *exception specification* of the function. If the
+predicate is false, the function has a *potentially-throwing exception
+specification*, otherwise it has a *non-throwing exception
+specification*. The exception specification is either defined
+implicitly, or defined explicitly by using a *noexcept-specifier* as a
+suffix of a function declarator ([[dcl.fct]]).
 ``` bnf
+noexcept-specifier:
     'noexcept' '(' constant-expression ')'
     'noexcept'
+    'throw' '(' ')'
 ```
+In a *noexcept-specifier*, the *constant-expression*, if supplied, shall
+be a contextually converted constant expression of type `bool` (
+[[expr.const]]); that constant expression is the exception specification
+of the function type in which the *noexcept-specifier* appears. A `(`
+token that follows `noexcept` is part of the *noexcept-specifier* and
+does not commence an initializer ([[dcl.init]]). The
+*noexcept-specifier* `noexcept` without a *constant-expression* is
+equivalent to the *noexcept-specifier* `noexcept(true)`. The
+*noexcept-specifier* `throw()` is deprecated ([[depr.except.spec]]),
+and equivalent to the *noexcept-specifier* `noexcept(true)`.
+If a declaration of a function does not have a *noexcept-specifier*, the
+declaration has a potentially throwing exception specification unless it
+is a destructor or a deallocation function or is defaulted on its first
+declaration, in which cases the exception specfication is as specified
+below and no other declaration for that function shall have a
+*noexcept-specifier*. In an explicit instantiation ([[temp.explicit]])
+a *noexcept-specifier* may be specified, but is not required. If a
+*noexcept-specifier* is specified in an explicit instantiation
+directive, the exception specification shall be the same as the
+exception specification of all other declarations of that function. A
+diagnostic is required only if the exception specifications are not the
+same within a single translation unit.
+If a virtual function has a non-throwing exception specification, all
 declarations, including the definition, of any function that overrides
+that virtual function in any derived class shall have a non-throwing
+exception specification, unless the overriding function is defined as
+deleted.
+[*Example 1*:
 ``` cpp
 struct B {
+  virtual void f() noexcept;
   virtual void g();
+  virtual void h() noexcept = delete;
 };
 struct D: B {
   void f();                     // ill-formed
+  void g() noexcept; // OK
+  void h() = delete;            // OK
 };
 ```
+The declaration of `D::f` is ill-formed because it has a
+potentially-throwing exception specification, whereas `B::f` has a
+non-throwing exception specification.
+— *end example*]
 Whenever an exception is thrown and the search for a handler (
+[[except.handle]]) encounters the outermost block of a function with a
+non-throwing exception specification, the function `std::terminate()` is
+called ([[except.terminate]]).
+[*Note 1*: An implementation shall not reject an expression merely
+because, when executed, it throws or might throw an exception from a
+function with a non-throwing exception specification. — *end note*]
+[*Example 2*:
 ``` cpp
+extern void f();                // potentially-throwing
+void g() noexcept {
+ f();                          // valid, even if f throws
+  throw 42; // valid, effectively a call to std::terminate
 }
 ```
+The call to `f` is well-formed even though, when called, `f` might throw
+an exception.
+— *end example*]
+An expression `e` is *potentially-throwing* if
+- `e` is a function call ([[expr.call]]) whose *postfix-expression* has
+  a function type, or a pointer-to-function type, with a
+  potentially-throwing exception specification, or
+- `e` implicitly invokes a function (such as an overloaded operator, an
+  allocation function in a *new-expression*, a constructor for a
+  function argument, or a destructor if `e` is a full-expression (
+  [[intro.execution]])) that is potentially-throwing, or
+- `e` is a *throw-expression* ([[expr.throw]]), or
+- `e` is a `dynamic_cast` expression that casts to a reference type and
+  requires a runtime check ([[expr.dynamic.cast]]), or
+- `e` is a `typeid` expression applied to a (possibly parenthesized)
+  built-in unary `*` operator applied to a pointer to a polymorphic
+  class type ([[expr.typeid]]), or
+- any of the immediate subexpressions ([[intro.execution]]) of `e` is
+  potentially-throwing.
+An implicitly-declared constructor for a class `X`, or a constructor
+without a *noexcept-specifier* that is defaulted on its first
+declaration, has a potentially-throwing exception specification if and
+only if any of the following constructs is potentially-throwing:
+- a constructor selected by overload resolution in the implicit
+  definition of the constructor for class `X` to initialize a
+  potentially constructed subobject, or
+- a subexpression of such an initialization, such as a default argument
+  expression, or,
+- for a default constructor, a default member initializer.
+[*Note 2*: Even though destructors for fully-constructed subobjects are
+invoked when an exception is thrown during the execution of a
+constructor ([[except.ctor]]), their exception specifications do not
+contribute to the exception specification of the constructor, because an
+exception thrown from such a destructor would call `std::terminate`
+rather than escape the constructor ([[except.throw]],
+[[except.terminate]]). — *end note*]
+The exception specification for an implicitly-declared destructor, or a
+destructor without a *noexcept-specifier*, is potentially-throwing if
+and only if any of the destructors for any of its potentially
+constructed subojects is potentially throwing.
+The exception specification for an implicitly-declared assignment
+operator, or an assignment-operator without a *noexcept-specifier* that
+is defaulted on its first declaration, is potentially-throwing if and
+only if the invocation of any assignment operator in the implicit
+definition is potentially-throwing.
+A deallocation function ([[basic.stc.dynamic.deallocation]]) with no
+explicit *noexcept-specifier* has a non-throwing exception
+specification.
+[*Example 3*:
 ``` cpp
 struct A {
+  A(int = (A(5), 0)) noexcept;
+  A(const A&) noexcept;
+  A(A&&) noexcept;
+  ~A();
 };
 struct B {
   B() throw();
+  B(const B&) = default; // implicit exception specification is noexcept(true)
+  B(B&&, int = (throw Y(), 0)) noexcept;
+  ~B() noexcept(false);
 };
+int n = 7;
 struct D : public A, public B {
+ int * p = new int[n];
+    // D::D() potentially-throwing, as the new operator may throw bad_alloc or bad_array_new_length
+    // D::D(const D&) non-throwing
+    // D::D(D&&) potentially-throwing, as the default argument for B's constructor may throw
+    // D::~D() potentially-throwing
 };
 ```
+Furthermore, if `A::~A()` were virtual, the program would be ill-formed
+since a function that overrides a virtual function from a base class
+shall not have a potentially-throwing exception specification if the
+base class function has a non-throwing exception specification.
+— *end example*]
+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. \[*Note 3*: 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 *noexcept-specifier* needs
+  the implicit exception specification to compare
+  against. — *end note*]
+The exception specification of a defaulted special member function is
 evaluated as described above only when needed; similarly, the
+*noexcept-specifier* of a specialization of a function template or
 member function of a class template is instantiated only when needed.

Diff to HTML by rtfpessoa