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

Proposed resolution (January, 2014):

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

The type of the lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type — called the closure type — whose properties are described below. This class type is not neither an aggregate (9.4.2 [dcl.init.aggr]) nor a literal type (6.8 [basic.types]). The closure type is declared...

Notes from the September, 2013 meeting:

At the suggestion of EWG, it was decided that closure types should be specified as not literal, rather than being unspecified as in the April, 2013 proposed resolution. The issue has thus been returned to "drafting" status.

Proposed resolution (April, 2013) [superseded]:

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

...An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing:

• the size and/or alignment of the closure type,

• whether the closure type is trivially copyable ( Clause 11 [class]),

• whether the closure type is a literal type (6.8 [basic.types]),

• whether the closure type is a standard-layout class ( Clause 11 [class]), or

• whether the closure type is a POD class ( Clause 11 [class]).

Additional note, April, 2013:

Some have expressed the opinion that such portability issues are just “par for the course,” and that specifying these characteristics at this point might unnecessarily limit the ability to extend the language in desirable directions at some point in the future.

The description of the characteristics of a closure class in 7.5.5 [expr.prim.lambda] leaves open the possibility that such a class might be a literal type, although it could also be a non-literal type. It would probably be good to specify that a closure class is not a literal type, in the interests of portability.

On a related note, it might be wise to remove the implementation freedom to make a closure class either a POD or not a POD; it seems only to be an invitation for portability problems with no real advantage.