[Moved to DR at the November, 2014 meeting.]

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.

Additional note (January, 2013):

The resolution conflicts with the current specification of operator delete: in 6.7.6.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.

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.)

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?