std::thread arguments (value vs. const)

If you want to pass reference, you have to wrap it into std::reference_wrapper thanks to std::ref. Like:

#include <functional>
#include <thread>

void my_function(int&);

int main()
{
    int my_var = 0;
    std::thread t(&my_function, std::ref(my_var));

    // ...
    t.join();
}

std::thread's arguments are used once.

In effect, it stores them in a std::tuple<Ts...> tup. Then it does a f( std::get<Is>(std::move(tup))...).

Passing std::get an rvalue tuple means that it is free to take the state from a value or rvalue reference field in the tuple. Without the tuple being an rvalue, it instead gives a reference to it.

Unless you use reference_wrapper (ie, std::ref/std::cref), the values you pass to std::thread are stored as values in the std::tuple. Which means the function you call is passed an rvalue to the value in the std::tuple.

rvalues can bind to const& but not to &.

Now, the std::tuple above is an implementation detail, an imagined implementation of std::thread. The wording in the standard is more obtuse.

Why does the standard say this happens? In general, you should not bind a & parameter to a value which will be immediately discarded. The function thinks that it is modifying something that the caller can see; if the value will be immediately discarded, this is usually an error on the part of the caller.

const& parameters, on the other hand, do bind to values that will be immediately discarded, because we use them for efficiency purposes not just for reference purposes.

Or, roughly, because

const int& x = 7;

is legal

int& x = 7;

is not. The first is a const& to a logically discarded object (it isn't due to reference lifetime extension, but it is logically a temporary).