This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Moved to DR at the November, 2014 meeting.]
The current wording of 9.5.2 [dcl.fct.def.default] paragraph 2 has some surprising implications:
An explicitly-defaulted function may be declared constexpr only if it would have been implicitly declared as constexpr, and may have an explicit exception-specification only if it is compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration.
In an example like
struct A {
A& operator=(A&);
};
A& A::operator=(A&) = default;
presumably the exception-specification of A::operator=(A&) is noexcept(false). However, attempting to make that exception-specification explicit,
A& A::operator=(A&) noexcept(false) = default;
is an error. Is this intentional?
Proposed resolution (February, 2014):
Change 14.5 [except.spec] paragraph 4 as follows:
...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. If a declaration of a function has an implicit exception-specification, other declarations of the function shall not specify an exception-specification. In an explicit instantiation...
(This resolution also resolves issue 1492.)
Additional note (January, 2013):
The resolution conflicts with the current specification of operator delete: in 6.7.5.5 [basic.stc.dynamic] paragraph 2, the two operator delete overloads are declared with an implicit exception specification, while in 17.6 [support.dynamic] paragraph 1, they are declared as noexcept.
Additional note (February, 2014):
The overloads cited in the preceding note have been independently changed in N3936 to include a noexcept specification, making the proposed resolution correct as it stands.