>> Unfortunately, the behavior differs from the test suite for >> std::is_convertible. In particular, this fails: >> >> static_assert(__is_convertible_to(int(int), int(&)(int)), ""); >> >> whereas this succeeds ) >> >> static_assert(is_convertible<int(int), int(&)(int)>::value, ""); > > > Hmm, that probably has to do with reference decay; we don't handle > conversion from reference type everywhere because there are no expressions > of reference type. So perhaps in the case of REFERENCE_TYPE can_convert > should build a dummy expression and call convert_from_reference; did your > CAST_EXPR work for this test?
No, not for this case. And for some reason, when I revisited the problems this morning, user-defined conversions weren't being handled for conversions between class types. It turns out that you do need an extra expression to force those lookups. I ran through every test in the is_convertible unit test with __is_convertible. There are 2 cases it doesn't address. The conversion of a function type (int()) to its reference type (int(&)()), and conversions between classes with implicit constructors or conversion functions. Looking at the other uses of can_convert, it seems like they mostly don't deal with those cases. So, can_convert *might* be extended to address these cases, but I'd rather be on the safe side and keep this as a separate function. Which I'm calling can_convert_implicitly, although may it should be called it is_convertible_to since it defines the semantics of __is_convertible_to. Andrew
call.patch
Description: Binary data
