>> 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. Andrew
reqexpr-4.patch
Description: Binary data
