Section: 184.108.40.206 [variant.ctor] Status: Open Submitter: Richard Smith Opened: 2016-11-28 Last modified: 2017-11-14
View other active issues in [variant.ctor].
View all other issues in [variant.ctor].
View all issues with Open status.
The library has lots of functions declared constexpr, but it's not clear what that means. The constexpr keyword implies that there needs to be some invocation of the function, for some set of template arguments and function arguments, that is valid in a constant expression (otherwise the program would be ill-formed, with no diagnostic required), along with a few side conditions. I suspect the library intends to require something a lot stronger than that from implementations (something along the lines of "all calls that could reasonably be constant subexpressions are in fact constant subexpressions, unless otherwise stated").[variant.ctor]/1 contains this, which should also be fixed:
"This function shall be constexpr if and only if the value-initialization of the alternative type T0 would satisfy the requirements for a constexpr function."
This is the wrong constraint: instead of constraining whether the function is constexpr, we should constrain whether a call to it is a constant subexpression.
Daniel:This is has some considerable overlap with LWG 2289 but is phrased in a more general way.
[2016-12-16, Issues Telecon]
Priority 2; this is also the general case of 2829.
[2017-02-20, Alisdair comments and suggests concrete wording]
Below is is draft wording I was working on at Issaquah to try to address both issues.
[2017-11 Albuquerque Wednesday issue processing]
Status to Open; really needs a paper.
STL says "What about plus<T>?" plus<int> needs to be usable in a constexpr context, but plus<string> can't be.
[2017-11 Albuquerque Saturday issues processing]
Geoffrey to write a paper resolving this.
This wording is relative to N4640.
Modify 220.127.116.11 [constexpr.functions] as indicated:
18.104.22.168 constexpr functions and constructors [constexpr.functions]
-1- This International Standard explicitly requires that certain standard library functions are constexpr (10.1.5 [dcl.constexpr]). . An implementation
shall notdeclare anystandard 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.