Movatterモバイル変換

This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20

2881. Type restrictions for the explicit object parameter of a lambda

[Accepted as a DR at the June, 2024 meeting.]

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

Proposed resolution (approved by CWG 2024-06-26):

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

   Given a lambda with alambda-capture, the type of the explicitobject parameter, if any, of the lambda's function call operator(possibly instantiated from a function call operator template) shallbe either:

   • the closure type
   • a class typepublicly and unambiguously derived fromthe closure type, or
   • a reference to a possibly cv-qualified such type.

2. 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 atype of void, or in which the return type is a function type or arraytype.
   • Attempting to give to an explicit object parameter ofa lambda's function call operator a type not permitted for such(7.5.6.2 [expr.prim.lambda.closure]).

CWG 2024-06-26

The following example is not supported by the proposed resolutionand 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();  }