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

2191. Incorrect result for noexcept(typeid(v))

[Adopted at the November, 2016 meeting as part of paper P0003R5.]

Consider the following example:

    struct B { virtual void f() { } };
    struct D : B { } d;
    bool b = noexcept(typeid(d));

According to 7.6.2.7 [expr.unary.noexcept] paragraph 3, the value of b should be false, because 14.5 [except.spec] bullet 14.6 says,

• If e is a typeid expression applied to a glvalue expression whose type is a polymorphic class type (7.6.1.8 [expr.typeid]), S consists of the type std::bad_typeid.

and d is such an expression. This is clearly bogus, as the expression cannot possibly throw; according to 7.6.1.8 [expr.typeid] paragraph 2, the condition under which the exception might be thrown is:

If the glvalue expression is obtained by applying the unary * operator to a pointer⁶⁹ and the pointer is a null pointer value (7.3.12 [conv.ptr]), the typeid expression throws an exception (14.2 [except.throw]) of a type that would match a handler of type std::bad_typeid exception (17.7.5 [bad.typeid]).

Proposed resolution (November, 2016):

Change 14.5 [except.spec] bullet 13.6 as follows:

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:

• ...

• If e is a typeid expression applied to a glvalue expression whose type is (possibly parenthesized) built-in unary * operator applied to a pointer to a polymorphic class type (7.6.1.8 [expr.typeid]), S consists of the type std::bad_typeid. [Example: ...