Type restrictions for the explicit object parameter of a lambda
tentatively ready
Section [expr.prim.lambda.closure]
Richard Smith

Created on 2024-04-19.00:00:00 last changed 4 weeks ago


Date: 2024-05-17.22:24:28

Proposed resolution (approved by CWG 2024-05-17):

  1. Change in [expr.prim.lambda.closure] paragraph 5 as follows:

    Given a lambda with a lambda-capture, the type of the explicit object parameter, if any, of the lambda's function call operator (possibly instantiated from a function call operator template) shall be either:
    • the closure type
    • a class type publicly and unambiguously derived from the closure type, or
    • a reference to a possibly cv-qualified such type.
  2. Add a new bullet after [temp.deduct.general] bullet 11.10:

    • ...
    • Attempting to create a function type in which a parameter has a type of void, or in which the return type is a function type or array type.
    • Attempting to give an invalid type to an explicit object parameter of a lambda-expression ( [expr.prim.lambda.closure]).
Date: 2024-04-19.00:00:00

Subclause [expr.prim.lambda.closure] paragraph 5 restricts the type of an explicit object parameter of a lambda to the closure type or classes derived from the closure type. It neglects to consider ambiguous or private derivation scenarios.

Date User Action Args
2024-05-17 22:24:28adminsetstatus: open -> tentatively ready
2024-04-20 08:55:52adminsetmessages: + msg7673
2024-04-19 00:00:00admincreate