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
On 06/21/2013 03:38 PM, Andrew Sutton wrote:
+ tree parms = cp_parser_parameter_declaration_clause (parser);
Calling this will push the parameter declarations into the current
binding level; you will want to add the begin_scope/leave_scope and
pop_binding that cp_parser_direct_declarator doe
On 06/21/2013 03:38 PM, Andrew Sutton wrote:
I haven't pushed this into a git branch since its a completely
separate change from the previous patch. Should I create a new branch
for separate work?
Sure.
Jason
Added a set of nodes to represent requirements inside of a requires
expression (EXPR_REQ, TYPE_REQ, NESTED_REQ), and a set of nodes
representing the actual checks of those requirements (VALIDEXPR_EXPR,
VALIDTYPE_EXPR, CONSTEXPR_EXPR).
The VALIDEXPR_EXPR, VALIDTYPE_EXPR, and CONSTEXPR_EXPR nodes ar
Andrew Sutton writes:
| Like this?
|
| // Parse a requires clause.
| //
| //requires-clause:
| // 'requires' logical-or-expression
| //
| // The required logical-or-expression must be a constant expression.
| static tree
| cp_parser_requires_clause (cp_parser *parser)
| {
| // Parse t
Like this?
// Parse a requires clause.
//
//requires-clause:
// 'requires' logical-or-expression
//
// The required logical-or-expression must be a constant expression.
static tree
cp_parser_requires_clause (cp_parser *parser)
{
// Parse the constant expression.
tree expr =
cp_par
Andrew Sutton writes:
| > | + // Concept extensions
| > | + case RID_REQUIRES:
| > | +return cp_parser_requires_expression (parser);
| > | +
| >
| > I think you meant here "nested requirements", not "extensions" as in
| > "GNU extensions" or "vendor lock-ins". We should continue with "nest
> | + // Concept extensions
> | + case RID_REQUIRES:
> | +return cp_parser_requires_expression (parser);
> | +
>
> I think you meant here "nested requirements", not "extensions" as in
> "GNU extensions" or "vendor lock-ins". We should continue with "nested
> requirements" then.
This denotes
Andrew Sutton writes:
| Attached is the stubbed out parsing for requires expressions. I plan
| on implementing semantics next.
See comments below.
| I haven't pushed this into a git branch since its a completely
| separate change from the previous patch. Should I create a new branch
| for separ
Attached is the stubbed out parsing for requires expressions. I plan
on implementing semantics next.
I haven't pushed this into a git branch since its a completely
separate change from the previous patch. Should I create a new branch
for separate work?
Changelog:
2013-06-21 Andrew Sutton
20 matches
Mail list logo
