This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-11-11

2047. Coordinating “throws anything” specifications

Section: 14.5  [except.spec]     Status: CD4     Submitter: Richard Smith     Date: 2014-11-18

[Adopted at the February, 2016 meeting.]

The resolutions of issues 330 and 1351 use different terminology for an exception specification that can throw anything: the former refers to a “(conceptual) set of all types,” while the latter uses a “pseudo-type, denoted by 'any'.” These should be unified.

Proposed resolution (October, 2015) [SUPERSEDED]:

  1. Change 14.5 [except.spec] paragraph 13 as follows:

    2. A The set of potential exceptions of a given context is either a type a set of types that might be thrown as an exception or a pseudo-type, denoted by “any”, that represents the situation where an exception of an arbitrary type might be thrown; the (conceptual) set of all types is used to denote that an exception of arbitrary type might be thrown. A subexpression e1 of an expression e is an immediate subexpression if there is no subexpression e2 of e such that e1 is a subexpression of e2.

  2. Delete 14.5 [except.spec] paragraph 14:

    3. The set of potential exceptions of a function, function pointer, or member function pointer f is defined as follows:

  3. Change 14.5 [except.spec] paragraph 15 as follows:

    4. The set of potential exceptions of an expression e is empty if e is a core constant expression (7.7 [expr.const]). Otherwise, it is the union of the sets of potential exceptions of the immediate subexpressions of e, including default argument expressions used in a function call, combined with a set S defined by the form of e, as follows:

    [Example: Given the following declarations

      void f() throw(int);
  void g();
  struct A { A(); };
  struct B { B() noexcept; };
  struct D() { D() throw (double); };

    the set of potential exceptions for some sample expressions is:

    —end example]

  4. Change 14.5 [except.spec] paragraph 16 as follows:

    5. Given a A member function f of some class X, where f is an inheriting constructor (_N4527_.12.9 [class.inhctor]) or an implicitly-declared special member function, the set of potential exceptions of the implicitly-declared member function f is considered to have an implicit exception specification that consists of all the members from the following sets...

  5. Delete the normative portion of 14.5 [except.spec] paragraph 17 and merge the note and example into the preceding paragraph, as follows:

    6. An inheriting constructor (_N4527_.12.9 [class.inhctor]) and an implicitly-declared special member function ( 11.4.4 [special]) are considered to have an implicit exception specification, as follows, where S is the set of potential exceptions of the implicitly-declared member function:

    [Note: An instantiation of an inheriting constructor template...

Additional note (November, 2015):

The base text underlying the preceding proposed resolution was changed at the October, 2015 meeting by the adoption of paper P0136R1. As a result, this issue has been returned to "drafting" status to allow reconciliation of the two sets of changes.

Proposed resolution (January, 2016):

  1. Change 14.5 [except.spec] paragraph 12 as follows:

    2. A The set of potential exceptions of a given context is either a type a set of types that might be thrown as an exception or a pseudo-type, denoted by “any”, that represents the situation where an exception of an arbitrary type might be thrown; the (conceptual) set of all types is used to denote that an exception of arbitrary type might be thrown. A subexpression e1 of an expression e is an immediate subexpression if there is no subexpression e2 of e such that e1 is a subexpression of e2.

  2. Delete 14.5 [except.spec] paragraph 13:

    3. The set of potential exceptions of a function, function pointer, or member function pointer f is defined as follows:

  3. Change 14.5 [except.spec] paragraph 14 as follows:

    4. The set of potential exceptions of an expression e is empty if e is a core constant expression (7.7 [expr.const]). Otherwise, it is the union of the sets of potential exceptions of the immediate subexpressions of e, including default argument expressions used in a function call, combined with a set S defined by the form of e, as follows:

    [Example: Given the following declarations

      void f() throw(int);
  void g();
  struct A { A(); };
  struct B { B() noexcept; };
  struct D { D() throw (double); };

    the set of potential exceptions for some sample expressions is:

    —end example]

  4. Change 14.5 [except.spec] paragraph 16 as follows:

    5. Given an An implicitly-declared special member function f of some class X, the set of potential exceptions of the implicitly-declared special member function f is considered to have an implicit exception specification that consists of all the members from the following sets:...

  5. Delete the normative text of 14.5 [except.spec] paragraph 17 and merge the example with the preceding paragraph:

    6. An implicitly-declared special member function ( 11.4.4 [special]) is considered to have an implicit exception specification, as follows, where S is the set of potential exceptions of the implicitly-declared special member function:

    [Example:...