This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [c++-concepts]: Requires expression
- From: Gabriel Dos Reis <gdr at axiomatics dot org>
- To: Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>
- Date: Sat, 22 Jun 2013 09:41:44 -0500
- Subject: Re: [c++-concepts]: Requires expression
- References: <CANq5SysOXY4RNkKz=-J926sKJ2H5E+k3pAtTmOOdgCoc0Kgd6A at mail dot gmail dot com> <87bo6z9gb3 dot fsf at euclid dot axiomatics dot org> <CANq5SytCVUEMdvDSYC+N2e=69k6JbsaKM5n3X95Pxx2_GTyRhQ at mail dot gmail dot com>
Andrew Sutton <andrew.n.sutton@gmail.com> 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 "nested
| > requirements" then.
|
| This denotes a primary expression, not a nested requirement. I was
| trying to subset the requirement like the "Objective-C++ expressions"
| comment just below it.
|
| I changed the comment to just "C++ concepts". We may get other primary
| expressions related to concepts, although I don't have any planned.
OK.
| > | +static inline tree
| > | +cp_parser_requires_clause (cp_parser *parser)
| > | +{
| > | + // Parse the constant expression.
| > | + tree expr =
| > | + cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR, NULL);
| > | + if (!require_potential_rvalue_constant_expression (expr))
| > | + return error_mark_node;
| > | + return expr;
| >
| > The grammar says "constant-expression". You should use
| > cp_parser_constant_expression.
|
| When we started talking about requirements, we didn't want the full
| breadth of an expression, so I limited it to a logical-or-expression
| that is also a constant expression. Commas, assignments, and
| conditions at the top-level seemed counter-intuitive.
I guess what I was saying earlier was that the comment preceding the
function said "constant-expression", and we want the code to match that.
I am not sure it is less counter-intuitive to allow non-toplevel comma
constant expression but disallow toplevel ones; they will all end up
being logical literal terms anyway. We shouldn't worry about
assignments, for we are enforcing the semantics constraints of constant
expressions.
| Do we want to allow any constant expression, or should we just change
| the docs to logical-or-expression that is also a constant expression?
Yes; and change the comments to say the grammar term is
logical-or-expression, with additional semantics constraint that they
must be constant expressions.
-- Gaby