Title
Dropping cv-qualification on members of closure objects
Status
cd2
Section
7.5.5 [expr.prim.lambda]
Submitter
Daveed Vandevoorde

Created on 2008-12-15.00:00:00 last changed 143 months ago

Messages

Date: 2009-07-15.00:00:00

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

Date: 2009-07-15.00:00:00

Proposed resolution (July, 2009)

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

Date: 2008-12-15.00:00:00

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.

History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: wp -> cd2
2009-11-08 00:00:00adminsetstatus: dr -> wp
2009-08-03 00:00:00adminsetmessages: + msg2236
2009-08-03 00:00:00adminsetstatus: review -> dr
2009-03-23 00:00:00adminsetmessages: + msg1900
2009-03-23 00:00:00adminsetstatus: open -> review
2008-12-15 00:00:00admincreate