Skip to content

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

Description

@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.

Activity

  1. jensmaurer commented on Nov 7, 2023

    @jensmaurer
    Member

    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.

  2. frederick-vs-ja commented on Nov 8, 2023

    @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.

  3. frederick-vs-ja commented on Jan 22, 2024

    @frederick-vs-ja
  4. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions