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