Re: Passing std::unique_ptr to std::thread's target

[...]
I have a guess, though: I assume that gcc does use std::bind internally
to implement the thread constructor. There exists currently a wording
problem described in LWG issue

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2021

for std::bind (and some other functions). The most recent proposed
resolution (not visible in the link above) suggests to change
[func.bind.bind] p3 as follows:

"Returns: A forwarding call wrapper g with a weak result type (20.8.2).
The effect of g(u1, u2, ..., uM) shall be INVOKE(fd,
<ins>std::forward<V1>(</ins>v1<ins>)</ins>,

<ins>std::forward<V2>(</ins>v2<ins>)</ins>, ...,
<ins>std::forward<VN>(</ins>vN<ins>)</ins>, result_of<FD cv <ins>&</ins>
(V1, V2, ..., VN)>::type), where cv represents the cv-qualifiers of g
and the values and types of the bound arguments v1, v2, ..., vN are
determined as specified below. [...]"

While LWG issue 2021 points to a defect in the wording of std::bind, the
intention clearly seems to be to provide lvalues of the "decayed"
functor and of the "decayed" functor arguments to the conceptual INVOKE
function,

so with or without the wording changes the problem will
probably remain for std::bind. This has the effect that if you replace
the line

std::thread thr(threadMain, std::move(outPtr));

by

std::bind(threadMain, std::move(outPtr))();

the code should be ill-formed. I find this decision a bit unfortunate
but I have been told that it must be necessary, because of
backward-compatibility reasons in regard to std::bind.