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

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 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 would be better to have a requirement that a particular
> expression instantiate into an actual constant expression.

I've disabled this feature for the time being with a "sorry" error.
I'll revisit the problem when I plug in the tsbust rules.

>> +// 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 conversion sequences.
>> +  tree expr = build_min (CAST_EXPR, type1);
>> +  return can_convert_arg (type2, type1, expr, LOOKUP_IMPLICIT, tf_none);
>> +}
> Can't you use can_convert instead of a new function?

Whatever problems I ran into previously don't seem to bother me now. I
removed this function in favor of using can_convert().

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, "");

Line 61 of the is_convertible test. I haven't tried fixing this one...

>> +  // Modify the declared parameters by removing their context (so they
>> +  // don't refer to the enclosing scope), and making the constant (so
>> +  // we can actually check constexpr properties).
> "marking them"?
> Does this actually work?

Sure did. This may not be relevant after the forthcoming changes to
how the constexpr test is actually implemented.

> This excludes expressions that just name a declaration.  I would expect
> 'expr && expr != error_mark_node' to do the right thing; was the TREE_TYPE
> check motivated by anything in particular?

In the formal model I'm designing, __is_valid_expr(e) evaluates to
true when e has a type. Although, if I'm instantiating a non-dependent
expression, I'll probably get an error_mark_node if the expression
can't be typed. Right?


Attachment: reqexpr-3.patch
Description: Binary data

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