[ 2020-06-08 Nina Dinka Ranns comments ]

The revised wording provided by LWG 2833 should resolve this issue as well.

[ 2016-12-14, Daniel comments ]

LWG 2833 overlaps considerably and both should be resolved together.

This wording is relative to N3691.

1. Change [pairs.pair] p2 as indicated:

   -2- The defaulted move and copy constructor, respectively, of pair shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr functionAn invocation of the move or copy constructor of pair shall be a constant expression ([expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of pair shall be a constant initializer for that pair object ([basic.start.init]) if all required element-wise initializations would be constant initializers for the respective subobjects.

2. Change [tuple.cnstr] p2 as indicated:

   -2- The defaulted move and copy constructor, respectively, of tuple shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr function. The defaulted move and copy constructor of tuple<> shall be constexpr functionsAn invocation of the move or copy constructor of tuple shall be a constant expression ([expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of tuple shall be a constant initializer for that tuple object ([basic.start.init]) if all required element-wise initializations would be constant initializers for the respective subobjects. An invocation of the move or copy constructor of tuple<> shall be a constant expression, or a constant initializer for that tuple<> object, respectively, if the function argument would be constant expression.

3. Change [time.duration] p7 as indicated:

   -7- Remarks: The defaulted copy constructor of duration shall be a constexpr function if and only if the required initialization of the member rep_ for copy and move, respectively, would satisfy the requirements for a constexpr function.An invocation of the copy constructor of duration shall be a constant expression ([expr.const]) if the required initialization of the member rep_ would be a constant expression. An invocation of the copy constructor of duration shall be a constant initializer for that duration object ([basic.start.init]) if the required initialization of the member rep_ would be constant initializers for this subobject.

[ Lenexa 2015-05-05 ]

STL : notice order of move/copy and copy/move with "respectively".

General word-smithing; ask for updated wording

Are we happy with this with changes we are suggesting?

unanimous

During the acceptance of N3471 and some similar constexpr papers, specific wording was added to pair, tuple, and other templates that were intended to impose implementation constraints that ensure that the observable constexpr "character" of a defaulted function template is solely determined by the required expressions of the user-provided types when instantiated, for example:

The defaulted move and copy constructor, respectively, of pair shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr function.

This wording doesn't require enough, especially since the core language via CWG 1358 does now support constexpr function template instantiations, even if such function cannot appear in a constant expression (as specified in [expr.const]) or as a constant initializer of that object (as specified in [basic.start.init]). The wording should be improved and should require valid uses in constant expressions and as constant initializers instead.