CWG2845 [temp.param] Make the type of lambda with no capture a structural type

[RungeCC]

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.

[jensmaurer]

This is a feature request, not a CWG issue: The standard is clear as written.

If you wish to pursue this feature request further, please submit a paper to WG21 for processing in EWG. See https://isocpp.org/std/submit-a-proposal for details.

[frederick-vs-ja]

FWIW, the status quo is not so that broken IMO - e.g. we can still write std::bind_front([](auto){}, 42) (since C++20) instead of intended std::bind_front<[](auto){}>(42) (invalid now, but may become valid in the future, possbily still in C++26). Given every lambda expression has a unique closure type, the closure object can always occupy zero byte in the resulted wrapper object, and thus the overhead (if any) of both forms can be considered equal.

[frederick-vs-ja]

CWG2845