3

Following code doesn't compile. Because pt has type of const std::packaged_task<void()>> and operator() is not const.

auto packagedTask = std::packaged_task<void()>>([]{}); auto future = packagedTask.get_future(); auto function = [pt = std::move(packagedTask)]{ (*pt)(); }); 

Here is workaround:

auto packagedTask = std::make_shared<std::packaged_task<void()>>([]{}); auto future = packagedTask->get_future(); auto function = [pt = std::move(packagedTask)]{ (*pt)(); }); 

Why local variables in the lambda object are const? I want to make first code work without overheads to workarounds. What is best practice to solve the issue?

1 Answer 1

6

Unless the lambda is marked as mutable, the generated lambda::operator() will be qualified as const. Marking your lambda as mutable will prevent this behavior:

auto function = [pt = std::move(packagedTask)]() mutable { (*pt)(); }); 

Why local variables in the lambda object are const?

Local variables in closures generated by lambda expressions are not const. It's the generated lambda::operator() that's qualified as const. A better question might be "Why is a lambda's operator() implicitly const?

It's because const is a better default than mutable. Mutability introduces complexity. Immutability makes code easier to reason about.

const should be the language-wide default, but that's impossible to change due to retrocompatibility. Since lambdas were a brand new feature, the committee decided to go with const by-default and opt-in mutability.

Sign up to request clarification or add additional context in comments.

2 Comments

Thanks! I need to store lambda objects in std::function but lambda with std::package_task cannot be assigned: std::function<void()> f = [pt = std::move(packagedTask)]() mutable { pt(); };
std::function does not support move-only callables: stackoverflow.com/questions/25330716/…

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.