Title
Incomplete specification of function pointer from lambda
Status
cd5
Section
7.5.5.2 [expr.prim.lambda.closure]
Submitter
Richard Smith

Created on 2014-06-05.00:00:00 last changed 40 months ago

Messages

Date: 2019-01-15.00:00:00

Proposed resolution (January, 2019):

  1. Change 7.5.5.2 [expr.prim.lambda.closure] paragraph 7 as follows, splitting it into two paragraphs:

  2. ...The value returned by this conversion function is the address of a function F that, when invoked, has the same effect as invoking the closure type's function call operator on a default-constructed instance of the closure type. F is a constexpr function if the function call operator is a constexpr function.

    For a generic lambda with no lambda-capture, the closure type has...

  3. Change 7.5.5.2 [expr.prim.lambda.closure] paragraph 9 as follows:

  4. The value returned by any given specialization of this conversion function template is the address of a function F that, when invoked, has the same effect as invoking the generic lambda's corresponding function call operator template specialization on a default-constructed instance of the closure type. F is a constexpr function if the corresponding specialization is a constexpr function and is an immediate function if the function call operator template specialization is an immediate function. [Note: This will result...
Date: 2019-02-15.00:00:00

[Accepted as a DR at the February, 2019 meeting.]

According to 7.5.5 [expr.prim.lambda] paragraph 6,

The closure type for a non-generic lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function with C ++ language linkage (9.11 [dcl.link]) having the same parameter and return types as the closure type's function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type's function call operator.

This does not mention the object for which the function call operator would be invoked (although since there is no capture, presumably the function call operator makes no use of the object pointer). This could be addressed by relating the behavior of the function call operator to a notional temporary, or the function call operator for such closure classes could be made static.

History
Date User Action Args
2020-12-15 00:00:00adminsetmessages: + msg6377
2020-12-15 00:00:00adminsetstatus: drafting -> cd5
2014-06-05 00:00:00admincreate