Re: [boost] [type_traits] Tests for implicit convertibility?

Subject: Re: [boost] [type_traits] Tests for implicit convertibility?
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2016-01-19 15:01:27

On 1/19/2016 4:18 PM, John Maddock wrote:
> Folks, I suspect we may have unintentionally backed ourselves into a
> corner with is_convertible/is_constructible.
>
> While trying to fix https://svn.boost.org/trac/boost/ticket/11922 I
> found I needed to SFINAE-out some conversion operators when the
> conversion already exists (as an implicit constructor in the target
> type).  So far so easy, but consider:
>
>
> class Int {
> public:
>     Int(const int& i) {};
>     Int(const Int& i) = delete;
> };
>
> static_assert(is_convertible<int, Int>::value, "Ooops");
>
> Now you would think this would pass right?  But it doesn't (at least on
> GCC and clang), and this is true for both boost:: and std:: type_traits
> and appears to be an unintended side effect of the way is_convertible is
> defined, that a valid copy constructor is required on the target type.

Just to clarify, a copy constructor is not required, a move constructor 
would do just fine here.

At Kona, EWG approved guaranteed copy elision (P0135), which if accepted 
would lift this artificial requirement.

> Of course:
>
> is_constructible<Int, int>::value
>
> is true, but that also catches explicit constructors.
>
> So... have we backed ourselves into a corner or do we still have a way
> to test for implicit-constructibilty that doesn't also require
> copy-constructibility on the target type?

By using existing traits (no, I don't think we need a new one)? How 
about `is_constructible<int, Int&&>` or `is_constructible<int, Int 
const&>`? Whether that's viable for you depends on your particular use 
case...

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com