https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71035
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-05-09
CC| |msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail| |4.9.3, 5.3.0, 6.1.0
Severity|normal |enhancement
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Hi Judy!
I'll take a stab at this -- let me know if I missed something. I agree that
similarly to the non-template case, (in the absence of a valid explicit
specialization) diagnosing the constexpr function template below would be
useful, even though in p5 and p6 of [dcl.constexpr], the standard leaves both
cases as a matter of QoI:
-6- If the instantiated template specialization of a constexpr function
template o member function of a class template would fail to satisfy the
requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor, even
though a call to such a function cannot appear in a constant expression. If no
specialization of the template would satisfy the requirements for a constexpr
function or constexpr constructor when considered as a non-template function or
constructor, the template is ill-formed; no diagnostic required.
(I read the last sentence as referring to implicit specializations of the
template definition, not explicit ones with valid definitions.)
Thus, I'm inclined to view this bug not as a defect but an enhancement request.
Let me know if you disagree.
Clang is more strict than GCC here by issuing the optional diagnostic.
My copy of EDG (version 4.10) rejects the program because it doesn't fully
implement the C++ 14 rules: a) it doesn't recognize void as a literal type, and
b) it doesn't allow statements in constexpr functions.
