Boost logo

Boost :

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 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


Agustín K-ballo Bergé.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at