This is the mail archive of the 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

>> 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(&)()),
> I looked into this a bit more; it seemed odd to consider any conversion from
> int() since there are no prvalues of function type.  The is_convertible
> trait is defined in terms of a conversion from an xvalue of the first type,
> so your __is_convertible_to trait should wrap type1 in an rvalue reference.
> That seems to give the correct result.

Wrapping with an rvalue reference doesn't always yield the right
result. In particular, in suppresses the checks for user-defined
conversions since the FROM type is not a class type any more.

I tried implementing this as if we had actually synthesized the
result-type conversion described by the standard (from create<From>()
to To), but I couldn't quite make it work. Somehow the rvalue
reference expression was being propagated into the conversion
functions, and (again) failing for user-defined conversion.

Eventually I ended up with a solution that (I think) conforms to the
intent of the specification, which is to transform type1 into
something that could plausibly be the result of create<From>().
Basically, I just wrap function types with an rvalue reference, and
passing everything else straight through.

> I disagree.  can_convert is not documented as only considering standard
> conversions, so it ought to handle user-defined conversions as well.  My
> preference would be to rename the current function and any needed uses to
> can_convert_standard, and give the name can_convert the intuitive meaning.

That's a good idea. I changed every existing use of can_convert to
can_convert_standard for the time being. That will preserve the
existing behavior, and we can determine which of the existing uses can
include user-defined conversions later.


Attachment: reqexpr-4.patch
Description: Binary data

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