2892. Relax the prohibition on libraries adding 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 38

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

  1. 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 constexprAn 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.