This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.
Section: 16.4.6.7 [constexpr.functions] Status: C++14 Submitter: Matt Austern Opened: 2010-11-12 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [constexpr.functions].
View all issues with C++14 status.
Discussion:
Suppose that a particular function is not tagged as constexpr in the standard, but that, in some particular implementation, it is possible to write it within the constexpr constraints. If an implementer tags such a function as constexpr, is that a violation of the standard or is it a conforming extension?
There are two questions to consider. First, is this allowed under the as-if rule? Second, if it does not fall under as-if, is there (and should there be) any special license granted to implementers to do this anyway, sort of the way we allow elision of copy constructors even though it is detectable by users?
I believe that this does not fall under "as-if", so implementers probably don't have that freedom today. I suggest changing the WP to grant it. Even if we decide otherwise, however, I suggest that we make it explicit.
[ 2011 Bloomington ]
General surprise this was not already in 'Ready' status, and so moved.
[ 2012 Kona ]
Some concern expressed when presented to full committee for the vote to WP status that this issue had been resolved without sufficient thought of the consequences for diverging library implementations, as users may use SFINAE to observe different behavior from otherwise identical code. Issue moved back to Review status, and will be discussed again in Portland with a larger group. Note for Portland: John Spicer has agreed to represent Core's concerns during any such discussion within LWG.
[2013-09 Chicago]
Straw poll: LWG strongly favoured to remove from implementations the freedom to add constexpr.
Matt provides new wording.
[2013-09 Chicago]
Move to Immediate after reviewing Matt's new wording, apply the new wording to the Working Paper.
Proposed resolution:
In 16.4.6.7 [constexpr.functions], change paragraph 1 to:
This standard explicitly requires that certain standard library functions are constexpr [dcl.constexpr]. An implementation shall not declare any standard library function signature as constexpr except for those where it is explicitly required. Within any header that provides any non-defining declarations of constexpr functions or constructors an implementation shall provide corresponding definitions.