On Thursday, 29 August 2019 21:55:57 EEST you wrote:

> I said people who don't care about moves, not people who don't care
> about whether their copies
> can now turn into moves. Like forwarding a prvalue of a lambda type or
> a wrapper thereof.
>
> What's the benefit of this change?

Ability to use move constructors and perform other in-place operations on
values captured by copy.

template <class LotsOfData>
void process_data(LotsOfData&& data)
{
    some_async_lib::call_later([=]() mutable {
        send_to_backup_server(std::move(data));
    });

    otherwise_process(data);
    finally_process(std::forward<LotsOfData>(data));
}

This currently works regardless of the type of data, lvalue or rvalue, const
or not. Except imagine that someone passes a const object to this function.
When the async library is juggling the callback, passing it from function to
function, putting it into queues and whatnot, it can't invoke the LotsOfData
move constructor, and that isn't permitted in the send_to_backup_server line
either. The proposed change will permit that, avoiding all the copies except
the single necessary one.

It's true that [data=data] is a valid workaround. But having to write that all
the time for all the captures or risk pessimization defeats the entire idea of
having [=], which is supposed to be equivalent to [x=x, y=y, ...] in the first
place.

-- 
WBR
Roman.