Fwd: [c++-concepts] Shorthand notation

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

I'm resending this patch for constrained template parameters for
review. It's been languishing for a while without review and it has
some interesting features in the implementation (namely, resolution
mechanism or constrained template parameters).

Andrew

---------- Forwarded message ----------
From: Andrew Sutton <andrew.n.sutton@gmail.com>
Date: Wed, Oct 16, 2013 at 9:59 AM
Subject: [c++-concepts] Shorthand notation
To: gcc-patches@gcc.gnu.org, Jason Merrill <jason@redhat.com>


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