2013/2/8 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com>:
>
> This looks like an error in the future_traits<T>::init overload set...it's
> missing an overload that a T const & can bind to (in the second argument).
>
> Also, I think it would be an improvement if set_value_at_thread_exit was
> able to catch rvalues as emulated rvalue references (when true rvalue
> references are unavailable) rather than as lvalue-reference-to-const.
>

Yes indeed, there is an overload resolution ambiguity.

Strictly speaking, it isn't an ambiguity that's causing the compiler failure, it's that the eligible overload set is empty.

I guess movable
/ emulation stuff in Thread is more difficult to manage since it
maintains 2 move emulations (original one from Thread and Move).

Yes :( I can imagine the maintenance nightmare for Vicente.

Move
already provides BOOST_RV_REF(T) macro which is T&& on compiler that
support it and rv<T>& when emulating and this imho is the argument
type future_traits<T>::init() should use to disambiguate.

Ideally, but the present implementation of set_value_at_thread_exit precludes init capturing by rvalue reference, AFAICT.

Is the original move emulation even still needed in Thread code.

I think there are subtle differences, perhaps not all of which have been worked out or discovered yet.

It
seems like half on BOOST_THREAD macros try to deal with move
semantics.

- Jeff