On 07/10/2013 08:24 AM, Andrew Sutton wrote:
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.
Let's le
>> 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
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
>> 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::value, "");
>
>
> Hmm, that probably has to do w
On 07/01/2013 01:27 PM, Andrew Sutton wrote:
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::value, "");
Hmm, tha
Updated with corrections for previous comments. New patch attached,
but the Changelog is essentially the same.
>> +/* A unary expression representing a requirement for an expression that
>> + can be evaluated at compile time. */
>
> Judging from the implementation, it seems that this relies on
> This seems to assume that there is a result-type-requirement.
>
>> +// Returns true if type1 can be implicitly converted to type2.
>> +static inline bool
>> +convertible_to_p (tree type1, tree type2)
>> +{
>> + // Build a "fake" conversion expression to force the lookup of user
>> + // defined
>> I was not aware of that. That's probably the right, but I remember
>> having some troubles getting that to work the way I wanted in the
>> previous implementation. It seemed like I actually had to evaluate the
>> expression to determine if it was actually constexpr.
>
>
> Right; an expression is
On 06/27/2013 04:56 PM, Andrew Sutton wrote:
I was not aware of that. That's probably the right, but I remember
having some troubles getting that to work the way I wanted in the
previous implementation. It seemed like I actually had to evaluate the
expression to determine if it was actually const
> Judging from the implementation, it seems that this relies on the notion of
> "potentially-constant expression" which is no longer part of the standard;
> that notion should only be used for diagnostics that are not required, not
> for things that participate in the type system.
>
> I think it wo
On 06/25/2013 09:27 AM, Andrew Sutton wrote:
+/* The REQ expressions are unary expressions that specific inididual
"specify"?
+/* A unary expression representing a requirement for an expression that
+ may be evaluated at compile time. */
The word "may" is ambiguous and should be avoided i
11 matches
Mail list logo
