This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Moved to DR at the November, 2014 meeting.]
According to 7.5.6 [expr.prim.lambda] paragraph 20,
The closure type associated with alambda-expression has a deleted(9.6.3 [dcl.fct.def.delete]) default constructor and a deleted copyassignment operator. It has an implicitly-declared copy constructor(11.4.5.3 [class.copy.ctor]) and may have an implicitly-declared moveconstructor (11.4.5.3 [class.copy.ctor]).
However, according to 11.4.5.3 [class.copy.ctor] paragraph 9,
If the definition of a classX does not explicitly declare a moveconstructor, one will be implicitly declared as defaulted if and only if
X does not have a user-declared copyconstructor,
X does not have a user-declared copy assignmentoperator,
X does not have a user-declared move assignment operator,and
X does not have a user-declared destructor.
It is not clear how this applies to the closure class. Would it bebetter to state that the closure class has a defaulted move constructorand a defaulted move assignment operator? There is already wording thathandles the case if they are ultimately defined as deleted.
Proposed resolution (October, 2014):
Change 7.5.6 [expr.prim.lambda] paragraph 20 as follows:
The closure type associated with alambda-expressionhasa deleted(9.6.3 [dcl.fct.def.delete])no defaultconstructor and a deleted copy assignment operator. It hasan implicitly-declareda defaulted copy constructor(11.4.5.3 [class.copy.ctor]) and may have animplicitly-declaredand a defaulted moveconstructor (11.4.5.3 [class.copy.ctor]). [Note:Thecopy/move constructor is implicitly defined in the same wayas any other implicitly declared copy/move constructor wouldbe implicitly definedThese special member functions areimplicitly defined as usual, and might therefore be defined asdeleted. —end note]