This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 113d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-04-05

1891. Move constructor/assignment for closure class

Section: 7.5.5.2  [expr.prim.lambda.closure]     Status: CD4     Submitter: Jonathan Caves     Date: 2014-03-10

[Moved to DR at the November, 2014 meeting.]

According to 7.5.5 [expr.prim.lambda] paragraph 20,

The closure type associated with a lambda-expression has a deleted (9.5.3 [dcl.fct.def.delete]) default constructor and a deleted copy assignment operator. It has an implicitly-declared copy constructor (11.4.5.3 [class.copy.ctor]) and may have an implicitly-declared move constructor (11.4.5.3 [class.copy.ctor]).

However, according to 11.4.5.3 [class.copy.ctor] paragraph 9,

If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if

It is not clear how this applies to the closure class. Would it be better to state that the closure class has a defaulted move constructor and a defaulted move assignment operator? There is already wording that handles the case if they are ultimately defined as deleted.

Proposed resolution (October, 2014):

Change 7.5.5 [expr.prim.lambda] paragraph 20 as follows:

The closure type associated with a lambda-expression has a deleted (9.5.3 [dcl.fct.def.delete]) no default constructor and a deleted copy assignment operator. It has an implicitly-declared a defaulted copy constructor (11.4.5.3 [class.copy.ctor]) and may have an implicitly-declared and a defaulted move constructor (11.4.5.3 [class.copy.ctor]). [Note: The copy/move constructor is implicitly defined in the same way as any other implicitly declared copy/move constructor would be implicitly defined These special member functions are implicitly defined as usual, and might therefore be defined as deleted. —end note]