Full name of submitter (unless configured in github; will be published with the issue): Runge C.

Reference (section label): [expr.prim.lambda.closure] and [temp.param]

Link to reflector thread (if any):

Issue description:

After CWG2542 was adopted, closure type is not a structural type as specified directly in [expr.prim.lambda.closure]/3:

The closure type is not an aggregate type ([dcl.init.aggr]) and not a structural type ([temp.param]).

However, there's no good reason why we should make all closure types non-structural since a closure object with no capture has already perfectly met the original definition of structural type. Notice closure type with generic lambda is not convertible to some function pointer (if did not specialize it) so IMO allowing them could improve the expressiveness (and/or, usability) of NTTP, especially in the current situation that we have accepted a facility proposal related to NTTP callable (P2714).

Suggested resolution:

Resolution 1

In [expr.prim.lambda.closure]/3:

The closure type is not an aggregate type ([dcl.init.aggr]) and not a structural type ([temp.param]).

Then in [temp.param]/7:

• a literal class type with the following properties:
  • all base classes and non-static data members are public and non-mutable and
  • the types of all bases classes and non-static data members are structural types or (possibly multidimensional) array thereof.and,
  • if the type of is a closure type ([expr.prim.lambda.closure]), the lambda-expression it is associated with has no lambda-capture.

Or:

Resolution 2

In [expr.prim.lambda.closure]/3:

The closure type is not an aggregate type ([dcl.init.aggr]) and not a structural type ([temp.param]). The closure type is not a structural type ([temp.param]) if the lambda-expression it is associated with has a lambda-capture.