Vrftsjtryk

I have a small "lambda expression" in the below function:

int main()

{

    int x = 10;

    auto lambda = [=] () { return x + 3; };

}

Below is the "anonymous closure class" generated for the above lambda expression.

int main()

{

    int x = 10;



    class __lambda_3_19

    {

        public: inline /*constexpr */ int operator()() const

        {

            return x + 3;

        }



        private:

            int x;



        public: __lambda_3_19(int _x) : x{_x}

          {}



    };



    __lambda_3_19 lambda = __lambda_3_19{x};

}

The closure's "operator()" generated by the compiler is implicitly const. Why did the standard committee make it const by default?

From cppreference

Unless the keyword mutable was used in the lambda-expression, the function-call operator is const-qualified and the objects that were captured by copy are non-modifiable from inside this operator()

In your case, there is nothing that, captured by copy, is modifiable.

I suppose that, if you write something as

int x = 10;



auto lambda = [=] () mutable { x += 3; return x; };

the const should disappear

-- EDIT --

The OP precise

I already knew that adding mutable will solve the issue. The question is that I want to understand the reason behind making the lambda immutable by default.

I'm not a language lawyer but this seems me obvious: if you make operator() not const, you can't make something as

template <typename F>

void foo (F const & f)

 { f(); }



// ...



foo({ std::cout << "lambda!" << std::endl; });

I mean... if operator() isn't const, you can't use lambdas passing they as const reference.

And when isn't strictly needed, should be an unacceptable limitation.

Found this paper by Herb Sutter at open-std.org which discusses this matter.

The odd couple: Capture by value’s injected const and quirky mutable

Consider this strawman example, where the programmer captures a local variable by value and tries to modify the captured value (which is a member variable of the lambda object):

int val = 0;

auto x = [=]( item e ) // look ma, [=] means explicit copy

 { use( e, ++val ); }; // error: count is const, need ‘mutable’

auto y = [val]( item e ) // darnit, I really can’t get more explicit

 { use( e, ++val ); }; // same error: count is const, need ‘mutable’

This feature appears to have been added out of a concern that the user might not realize he got a copy, and in particular that since lambdas are copyable he might be changing a different lambda’s copy.

The above quote and example indicate why the Standards Committee might have made it const by default and required mutable to change it.

I think, it is simply to avoid confusion when a variable inside a lambda refer not to what was originally captured. Lexically such a variable is as if in scope of its "original". Copying is mainly to allow to extend the lifetime of object. When a capture is not by copy it refers to original and modifications are applied to the original, and there is no confusion because of two different objects (one of which is implicitly introduced), and it is allowed by lambda's const function call operator.