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

2024-07-24


346. Typo in 15.4

Section: 14.5  [except.spec]     Status: NAD     Submitter: Lois Goldthwaite     Date: 18 March 2002

14.5 [except.spec] paragraph 13 contains the following text. I believe 'implicitLY' marked below should be replaced with 'implicit.'

An implicitly declared special member function (11.4.4 [special]) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, destructor, or copy 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 implicitly 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. [Example:

    struct A {
        A();
        A(const A&) throw();
        ~A() throw(X);
    };
    struct B {
        B() throw();
        B(const B&) throw();
        ~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()   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. ]

The example code shows structs whose destructors have exception specifications which throw certain types. There is no defect here, but it doesn't sit well with our general advice elsewhere that destructors should not throw. I wish I could think of some other way to illustrate this section.

Notes from October 2002 meeting:

This was previously resolved by an editorial change.