Re: [boost] is_convertible problems associated with move-only types

Subject: Re: [boost] is_convertible problems associated with move-only types
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2009-01-06 11:28:18

On Jan 6, 2009, at 10:45 AM, David Abrahams wrote:

>
> on Mon Jan 05 2009, Howard Hinnant <hinnant-AT-twcny.rr.com> wrote:
>
>> I'm continuing to refine a boost::unique_ptr emulation and testsuite.
>
> Howard, can you put this in the sandbox?  I know there are a number of
> us who would like very much to collaborate on it.

I will make it available as soon as I can at http://home.roadrunner.com/~hinnant/unique_ptr03.html

There will be plenty of room for collaboration.  Indeed I feel like  
that is already happening with the discussion in this thread.

>> One thing I've just uncovered is that I'm hitting a brick wall with
>> is_convertible and move-only deleters used within the unique_ptr move
>> constructor.  The problem is that boost::is_convertible<From, To>
>> assumes From is an lvalue.
>
> Sorry to be nitpicky, but that's not making sense to me.  IIUC the  
> terms
> lvalue and rvalue can only apply to expressions, not types.  Are you
> saying that From has to be a reference type?  Surely not.

I'm saying that if you construct a To from a From, you /may/ get  
different answers (on whether the construction works or not) depending  
upon if you consider From an lvalue or rvalue:

 From f;
To t1 = f;  // one answer
To t2 = From();  // potentially a different answer

More specifically, if To and From are the same move-only type (say  
unique_ptr<int>), then you /do/ get a different answer.

That being said, the vast majority of the is_convertible use cases  
simply don't care if the source is considered an lvalue or rvalue.   
E.g.:

    is_convertible<T*, U*>::value

(same answer either way with pointers)

>> is_convertible<Deleter, Deleter> gets  instantiated and it is all  
>> over.
>
> Specifically, how?

The boost::is_convertible implementation requires access to a Deleter  
copy constructor.  My modifications to the boost::is_convertible  
implementation treat the From as an rvalue and will attempt the  
"auto_ptr solution" for making a copy from an rvalue when From is an  
emulated move-only type (avoiding the Deleter copy constructor, and  
using the conversion to the rv<Deleter> instead).

>> I've modified my copy of is_convertible (without really knowing  
>> what I'm doing) like
>> so:
>>
>> Index: is_convertible.hpp
>> ===================================================================
>> --- is_convertible.hpp	(revision 50433)
>> +++ is_convertible.hpp	(working copy)
>> @@ -119,6 +119,8 @@
>> struct any_conversion
>> {
>>     template <typename T> any_conversion(const volatile T&);
>> +    template <typename T> any_conversion(volatile T&);
>> +    template <typename T> any_conversion(const T&);
>>     template <typename T> any_conversion(T&);
>> };
>>
>> @@ -131,8 +133,8 @@
>> template <typename From, typename To>
>> struct is_convertible_basic_impl
>> {
>> -    static From _m_from;
>> -    static bool const value =  
>> sizeof( detail::checker<To>::_m_check(_m_from, 0) )
>> +    static From _m_from();
>> +    static bool const value =  
>> sizeof( detail::checker<To>::_m_check(_m_from(), 0) )
>>         == sizeof(::boost::type_traits::yes_type);
>> };
>
> Note the From above is not the same as the one below at least in the
> current code.

I ran svn update on the boost-trunk before creating this diff.

>> @@ -291,7 +293,8 @@
>> template <typename From, typename To>
>> struct is_convertible_impl
>> {
>> -    typedef typename add_reference<From>::type ref_type;
>> +//    typedef typename add_reference<From>::type ref_type;
>> +    typedef From ref_type;
>>     BOOST_STATIC_CONSTANT(bool, value =
>>         (::boost::type_traits::ice_and<
>>             ::boost::type_traits::ice_or<
>
> So it used to pass an lvalue of type _m_from, and after your change it
> passes an rvalue.  Of course, your change now assumes that From can be
> returned from a function.  I think you'll have a problem if you try  
> this
> with From being a noncopyable non-movable type.
>
>
>> This hits just the part targeting gcc.
>
> (and old Borland compilers).
>
>> The intent is that in boost::is_convertible<From, To> From is now
>> considered an rvalue (unless From is a (lvalue) reference type).   
>> This
>> makes my test case happy.  I can now move construct a unique_ptr with
>> a move-only deleter.
>>
>> Fwiw, this definition of is_convertible is consistent with  
>> std::is_convertible in
>> N2800:
>
> I was just going to ask that.

To emulate the N2800 definition in C++03 one must treat void, array  
and function types specially in the implementation (arrays and  
functions can't be returned from functions and void can't be a  
function parameter).  Even so, a C++03 library emulation will get  
noncopyable non-movable types wrong (as will the current  
boost::is_convertible).  It will report a compile time error instead  
of false.  However C++03 /can/ get noncopyable movable types right,  
but only if From is considered an rvalue.  If the client specifically  
wants to consider From an lvalue, he can:

    is_convertible<From&, To>::value

This is not a newly discovered problem with is_convertible and move- 
only types:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html#rel
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html#rel

-Howard