Re: [boost] [repost] Futures Review - can move_dest_type be public?

Subject: Re: [boost] [repost] Futures Review - can move_dest_type be public?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-10 12:38:00

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, February 10, 2009 6:22 PM
Subject: Re: [boost] [repost] Futures Review - can move_dest_type be public?

> 
> "vicente.botet" <vicente.botet_at_[hidden]> writes:
> 
>>> Hi,
>>> 
>>> The function get is defined in the documentation with following prototypes
>>> 
>>>    R&& unique_future::get();
>>>    R& unique_future<R&>::get();
>>>    void unique_future<void>::get();
>>> 
>>> But when the move semantic is emulated this is just translated as 
>>> 
>>>        move_dest_type get()
>>> 
>>> with move_dest_type defined depending on the future template parameter as follows
>>> 
>>>        typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
>>> 
>>>        template<typename T>
>>>        struct future_traits
>>>        {
>>> #ifdef BOOST_HAS_RVALUE_REFS
>>>            typedef T const& source_reference_type;
>>>            struct dummy;
>>>            typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type;
>>>            typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type;
>>> #else
>>>            typedef T& source_reference_type;
>>>            typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type;
>>>            typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T>::type move_dest_type;
>>> #endif
>>> 
>>>        };
>>> 
>>> Generic libraries using the futures needs to get the type returned by
>>> get. What do you think about making the move_dest_type public at
>>> least when BOOST_HAS_RVALUE_REFS is not defined? Another option would
>>> be to make public the future_traits class.
> 
> That's an interesting idea. I can see the benefit of being able to know
> the type of unique_future<T>::get() without having to use
> decltype/BOOST_TYPEOF.
> 
> Maybe a unique_future<T>::get_result_type typedef would be most
> appropriate.

This will be Ok to my needs.

Thanks,
Vicente