Movatterモバイル変換

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

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]

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.