[Voted into the WP at the March, 2011 meeting as part of paper N3262.]

Proposed resolution (November, 2010) [SUPERSEDED]:

Change 9.2.6 [dcl.constexpr] paragraph 6 as follows:

If the instantiated template specialization of a constexpr function template or member function of a class template would fail to satisfy the requirements for a constexpr function or constexpr constructor, that specialization is not a constexpr function or constexpr constructor. [Note: if the function is a member function it will still be const as described below. Implementations are encouraged to issue a warning if a function is rendered not constexpr by a non-dependent construct. —end note] If no specialization of the template would yield a constexpr function or constexpr constructor, the program is ill-formed; no diagnostic required.

9.2.6 [dcl.constexpr] paragraph 5 says,

If the instantiated template specialization of a constexpr function template or member function of a class template would fail to satisfy the requirements for a constexpr function or constexpr constructor, that specialization is not a constexpr function or constexpr constructor. [Note: if the function is a member function it will still be const as described below. Implementations are encouraged to issue a warning if a function is rendered not constexpr by a non-dependent construct. —end note]

A non-dependent error in a function template renders it ill-formed with no diagnostic required (13.8 [temp.res] paragraph 8). A similar approach is being taken in the proposed resolution of issue 1125 with respect to constexpr functions. It would be more consistent to treat constexpr function templates in the same way, along the lines of

If no specialization of the template would be constexpr, the program is ill-formed, no diagnostic required.