Fwd: [c++-concepts] Shorthand notation

2014-03-06 Thread Andrew Sutton
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.sut...@gmail.com
Date: Wed, Oct 16, 2013 at 9:59 AM
Subject: [c++-concepts] Shorthand notation
To: gcc-patches@gcc.gnu.org, Jason Merrill ja...@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:

  templatetypename T, FunctionT 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:

  templateClass... Ts // ClassT() must be true for each T in Ts
void f();

The transformation is:

  templatetypename... Ts
requires ClassTs()...
  void f();

Where ClassTs()... expands to ClassT1()  ClassT2()  ... 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.sut...@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


Re: [c++-concepts] Shorthand notation

2013-10-18 Thread Andrew Sutton
A small follow up change. This removes the sorry from concept name
resolution. Committed in r203815.

2013-10-16  Andrew Sutton  andrew.n.sut...@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.sut...@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:

   templatetypename T, FunctionT 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:

   templateClass... Ts // ClassT() must be true for each T in Ts
 void f();

 The transformation is:

   templatetypename... Ts
 requires ClassTs()...
   void f();

 Where ClassTs()... expands to ClassT1()  ClassT2()  ... 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.sut...@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


short-2.patch
Description: Binary data


Re: [c++-concepts] Shorthand notation

2013-10-18 Thread Paolo Carlini

Hi,

On 10/18/2013 02:23 PM, Andrew Sutton wrote:

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

2013-10-16  Andrew Sutton  andrew.n.sut...@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.
Nit: normally this would be just * constraint.cc, because the paths are 
relative to the location of the corresponding ChangeLog file (which is 
under gcc/cp)


Thanks!
Paolo.


Re: [c++-concepts] Shorthand notation

2013-10-18 Thread Andrew Sutton
I know. When I started working on the project, Gaby asked that I keep
all concept-related changes in the top-level Changelog.concepts with
full paths for the file names.

Andrew Sutton


On Fri, Oct 18, 2013 at 8:53 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
 Hi,


 On 10/18/2013 02:23 PM, Andrew Sutton wrote:

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

 2013-10-16  Andrew Sutton  andrew.n.sut...@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.

 Nit: normally this would be just * constraint.cc, because the paths are
 relative to the location of the corresponding ChangeLog file (which is under
 gcc/cp)

 Thanks!
 Paolo.


[c++-concepts] Shorthand notation

2013-10-16 Thread Andrew Sutton
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:

  templatetypename T, FunctionT 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:

  templateClass... Ts // ClassT() must be true for each T in Ts
void f();

The transformation is:

  templatetypename... Ts
requires ClassTs()...
  void f();

Where ClassTs()... expands to ClassT1()  ClassT2()  ... 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.sut...@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