Re: [c++-concepts] Shorthand notation

[Andrew Sutton <andrew dot n dot sutton at gmail dot com>]

A small follow up change. This removes the "sorry" from concept name
resolution. Committed in r203815.

2013-10-16  Andrew Sutton  <andrew.n.sutton@gmail.com>
        * gcc/cp/constraint.cc (finish_concept_name): Allow functions with
        the same name as concepts to resolve as call expressions in the
        usual way.

Andrew Sutton


On Wed, Oct 16, 2013 at 9:59 AM, Andrew Sutton
<andrew.n.sutton@gmail.com> wrote:
> I've committed initial support for shorthand constraints. This patch
> adds support for parsing a concept-names as non-class names. When
> introducing a template parameter, the concept name is transformed into
> a constraint on the template parameter. Constrained parameters can
> introduce type, non-type and template template parameters.
>
> This has initial support for variadic constraints, but it's not well tested.
>
> This patch does not yet support default arguments for constrained
> template parameters, nor does it support the use of concept ids of
> this form:
>
>   template<typename T, Function<T> F>
>     void f();
>
> There are a couple of interesting things in the patch. I'm using a
> PLACEHOLDER_EXPR as a template argument in order to resolve constraint
> names. Effectively, I deduce concepts by creating an expression like:
>
>   Equality_comparable<?>()
>
> where ? is a placeholder, and after coerce_template_arguments
> completes, I can extract the matched parameter from the placeholder.
> This works nicely when concepts are overloaded or have default
> arguments (although I'm not sure I'm testing that very thoroughly
> right now).
>
> With variadic constraints, I've had to add functionality to expand a
> pack as a conjunction of requirements. For example, if you declare:
>
>   template<Class... Ts> // Class<T>() must be true for each T in Ts
>     void f();
>
> The transformation is:
>
>   template<typename... Ts>
>     requires Class<Ts>()...
>   void f();
>
> Where Class<Ts>()... expands to Class<T1>() && Class<T2>() && ... etc.
> I feel like the current implementation is a bit hacky, and I'm
> wondering if I should introduce a new node for a pack conjunction.
>
> Change log follows.
>
> 2013-10-16  Andrew Sutton  <andrew.n.sutton@gmail.com>
>         * gcc/cp/constraint.cc (conjoin_requiremens): New.
>         (resolve_constraint_check): Filter non-concept candidates before
>         coercing arguments. Perform deduction in a template-decl processing
>         context to prevent errors during diagnosis.
>         (finish_concept_name), (finish_shorthand_requirement),
>         (get_shorthand_requirements): New.
>         * gcc/cp/pt.c (template_parm_to_arg): Make non-static.
>         (process_templat_parm): Build shorthand requirements from the
>         parameter description.
>         (end_templat_parm_list): New.
>         (convert_placeholder_argument): New.
>         (convert_template_argument): Match placeholder arguments against
>         any template parameter.
>         (tsubst_pack_conjuction):  New.
>         (tsubst_expr): Expand a pack as a conjunction.
>         (type_dependent_expression_p): Placeholders are always type
>         dependent.
>         * gcc/cp/parser.c (cp_is_constrained_parameter),
>         (cp_finish_template_type_parm), (cp_finish_template_template_parm)
>         (cp_finish_non_type_template_parm), (cp_finish_constrined_parameter):
>         New.
>         (cp_parser_template_parameter): Handle constrained parameters.
>         (cp_parser_nonclass_name): An identifier naming an overload set
>         may declare a constrained parameter.
>         (cp_parser_type_parameter), (cp_parser_template_declaration_after_exp):
>         Get shorthand requirements from the tmeplate parameter list.
>         * gcc/cp/cp-tree.h (TEMPLATE_PARM_CONSTRAINTS): New.
>
> Committed in 203704.
>
> Andrew Sutton

Attachment: short-2.patch
Description: Binary data