Created on 2014-06-05.00:00:00 last changed 7 months ago
Proposed resolution (January, 2019):
Change 220.127.116.11 [expr.prim.lambda.closure] paragraph 7 as follows, splitting it into two paragraphs:
...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 . 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...
Change 18.104.22.168 [expr.prim.lambda.closure] paragraph 9 as follows:
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 . F is a constexpr function if the corresponding specialization is a constexpr function . [Note: This will result...
[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.
|2020-12-15 00:00:00||admin||set||messages: + msg6377|
|2020-12-15 00:00:00||admin||set||status: drafting -> cd5|