Created on 2024-04-19.00:00:00 last changed 4 days ago
CWG 2024-06-26
The following example is not supported by the proposed resolution and remains ill-formed:
int main() { int x = 0; auto lambda = [x] (this auto self) { return x; }; using Lambda = decltype(lambda); struct D : private Lambda { D(Lambda l) : Lambda(l) {} using Lambda::operator(); friend Lambda; } d(lambda); d(); }
Proposed resolution (approved by CWG 2024-06-26):
Change in 7.5.6.2 [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.
Add a new bullet after 13.10.3.1 [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 to an explicit object parameter of a lambda's function call operator a type not permitted for such (7.5.6.2 [expr.prim.lambda.closure]).
[Accepted as a DR at the June, 2024 meeting.]
Subclause 7.5.6.2 [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.
History | |||
---|---|---|---|
Date | User | Action | Args |
2024-12-17 09:54:02 | admin | set | status: dr -> drwp |
2024-07-20 13:52:34 | admin | set | status: ready -> dr |
2024-06-27 04:25:11 | admin | set | messages: + msg7758 |
2024-06-26 20:13:04 | admin | set | status: tentatively ready -> ready |
2024-05-17 22:24:28 | admin | set | status: open -> tentatively ready |
2024-04-20 08:55:52 | admin | set | messages: + msg7673 |
2024-04-19 00:00:00 | admin | create |