Title
Do library implementers have the freedom to add constexpr?
Status
c++14
Section
[constexpr.functions]
Submitter
Matt Austern

Created on 2010-11-12.00:00:00 last changed 130 months ago

Messages

Date: 2013-09-27.14:42:28

Proposed resolution:

In [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.

Date: 2013-09-29.11:37:54

[ 2013-09 Chicago ]

Move to Immediate after reviewing Matt's new wording, apply the new wording to the Working Paper.

Date: 2013-09-25.19:08:46

[ 2013-09 Chicago ]

Straw poll: LWG strongly favoured to remove from implementations the freedom to add constexpr.

Matt provides new wording.

Date: 2012-02-12.18:36:43

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

Date: 2011-08-18.12:47:33

[ 2011 Bloomington ]

General surprise this was not already in 'Ready' status, and so moved.

Date: 2010-11-12.00:00:00

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.

History
Date User Action Args
2014-02-20 13:20:35adminsetstatus: wp -> c++14
2013-09-29 11:37:54adminsetstatus: immediate -> wp
2013-09-27 14:42:28adminsetmessages: + msg6648
2013-09-27 14:42:28adminsetstatus: review -> immediate
2013-09-25 19:08:46adminsetmessages: + msg6616
2012-02-12 18:36:43adminsetmessages: + msg5995
2012-02-12 18:36:43adminsetstatus: voting -> review
2012-02-09 04:07:48adminsetstatus: ready -> voting
2011-08-18 12:47:33adminsetmessages: + msg5866
2011-08-18 12:47:33adminsetstatus: new -> ready
2010-11-13 13:40:40adminsetmessages: + msg5355
2010-11-12 00:00:00admincreate