You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CWG2845 [temp.param] Make the type of lambda with no capture a structural type #459
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.
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.
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.
changed the title [-][temp.param] Make the type of lambda with no capture a structural type[/-][+]CWG2845 [temp.param] Make the type of lambda with no capture a structural type[/+]on Jan 22, 2024
Activity
jensmaurer commentedon Nov 7, 2023
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 commentedon Nov 8, 2023
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 intendedstd::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 commentedon Jan 22, 2024
CWG2845
[-][temp.param] Make the type of lambda with no capture a structural type[/-][+]CWG2845 [temp.param] Make the type of lambda with no capture a structural type[/+]