This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
constexpr
Section: 16.4.6.7 [constexpr.functions] Status: NAD Submitter: Great Britain Opened: 2017-02-03 Last modified: 2020-09-06
Priority: 1
View all other issues in [constexpr.functions].
View all issues with NAD status.
Discussion:
Addresses GB 38Relax the prohibition on libraries adding constexpr
; this was a constraint requested by library implementers when
constexpr
was new, and those same implementers now feel unduly constrained.
Proposed change: Rewrite the whole sub-clause to support libraries adding constexpr
in a compatible manner,
much like the freedom to add a noexcept
specification.
[2017-02-20, Marshall adds wording]
The simplest change would be to strike the sentence "An implementation shall not […] explicitly required". However, people seem to want a definite permission here, so I have provided one.
[2017-07 Toronto Thurs Issue Prioritization]
Priority 1
[2018-06 Rapperswil Thursday issues processing]
This is a feature request; not a defect. We've had two cross-group meetings over this, and there is no consensus for changing this. Closing as NAD.
Proposed resolution:
This wording is relative to N4640.
Modify 16.4.6.7 [constexpr.functions] as indicated:
This International Standard explicitly requires that certain standard library functions are constexpr (7.1.5). An implementation may declare additional standard library function signatures as 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.