This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [c++-concepts] requires expression semantics


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

Attachment: call.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]