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

Proposed resolution (July, 2009)

See document PL22.16/09-0117 = WG21 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.