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

2023-01-15


756. Dropping cv-qualification on members of closure objects

Section: 7.5.5.2  [expr.prim.lambda.closure]     Status: CD2     Submitter: Daveed Vandevoorde     Date: 15 December, 2008

[Voted into the WP at the July, 2009 meeting as part of N2927.]

Consider the following example:

    void f() {
      int const N = 10;
      [=]() mutable { N = 30; }  // Okay: this->N has type int, not int const.
      N = 20;  // Error.
    }

That is, the N that is a member of the closure object is not const, even though the captured variable is const. This seems strange, as capturing is basically a means of capturing the local environment in a way that avoids lifetime issues. More seriously, the change of type means that the results of decltype, overload resolution, and template argument deduction applied to a captured variable inside a lambda expression can be different from those in the scope containing the lambda expression, which could be a subtle source of bugs.

On the other hand, the copying involved in capturing has uses beyond avoiding lifetime issues (taking snapshots of values, avoiding data races, etc.), and the value of a cv-qualified object is not cv-qualified.

Proposed resolution (July, 2009)

See document PL22.16/09-0117 = WG21 N2927.