This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-04-18
[Voted into WP at March, 2010 meeting.]
There is no prohibition against specifying a function type in an exception-specification, and the normal conversion of a function type to a pointer-to-function type occurs in both throw-expressions (14.2 [except.throw] paragraph 3) and in handlers (14.4 [except.handle] paragraph 2), but that was apparently overlooked in the description of exception-specifications.
Proposed resolution (February, 2010):
Change 14.5 [except.spec] paragraphs 2-3 as follows:
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.
If any declaration of a function has an exception-specification, all declarations, including the definition and
anany explicit specialization, of that function shall have an exception-specification with the same set oftype-idsadjusted types. 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 an exception-specification with the same set oftype-idsadjusted types. 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 have the same set oftype-idsadjusted types as other declarations of that function. A diagnostic is required only if the sets oftype-idsadjusted types are different within a single translation unit.