This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [c++-concepts] requires expression semantics
- From: Jason Merrill <jason at redhat dot com>
- To: Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Gabriel Dos Reis <gdr at axiomatics dot org>
- Date: Mon, 08 Jul 2013 13:55:37 -0400
- Subject: Re: [c++-concepts] requires expression semantics
- References: <CANq5SyvWKM8dm_Qaiu2_UHqXyWU=6tetPrEwhuZH3i+DYd42Xg at mail dot gmail dot com> <51CC7AC4 dot 9070400 at redhat dot com> <CANq5Syu9hxwKk8qma1Chc3NtqdtU9+EKjAzs3ZusTmYN5Q18Kg at mail dot gmail dot com> <51D44F61 dot 5040701 at redhat dot com> <CANq5Syt-Zkf-41OWUKTPdZQmpF0cBx2eF04imobhDtrtOR7v8A at mail dot gmail dot com>
On 07/04/2013 11:30 AM, Andrew Sutton wrote:
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.
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.
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.
Jason