Re: [PATCH 4/4] Support using 'auto' in a function parameter list to introduce an implicit template parameter.

[Adam Butcher <adam at jessamine dot co dot uk>]

On 01.09.2013 22:20, Jason Merrill wrote:
> On 08/27/2013 03:42 PM, Adam Butcher wrote:
> > +  else // extend current template parameter list
> > +      // pop the innermost template parms into tparms
>
> Most comments should start with a capital letter and end with a 
> period.
Will change.

> > +      for (size_t n = 0, end = TREE_VEC_LENGTH (inner_vec); n < 
> > end; ++n)
> > +	tparms = chainon (tparms, TREE_VEC_ELT (inner_vec, n));
>
> Doing chainon in a loop has bad algorithmic complexity, as it walks
> through the whole tparms list each iteration.  Better to build up a
> list from inner_vec and then chainon that list as a whole.
Okay.

> > +template <typename TreePredicate>
> > +inline tree
> > +find_type_usage (tree t, TreePredicate pred)
>
> I don't think this needs to be a template, since we know the
> predicates take a single tree and return bool.
I didn't know whether to allow for someone passing in a stateful
lambda (or other functor) in future so I avoided the issue by
making the predicate a template type param.  If we're happy that
only c-style functions (or stateless lambdas) will be passed then
I'll put it back as 'bool (*) (const_tree)'.

> I don't see any diagnostic for the implicit function template
> extension; my earlier comment about not controlling it with 
> -std=c++1y
> vs gnu++1y didn't mean it should go away entirely.  :)
>
> Maybe we should call it part of c++1z, or just control the diagnostic
> with -pedantic.
I must confess I was a bit unclear about how to proceed there.  I'll
reinstate the two messages and go with a specific diagnostic if
-pedantic is set in the non-lambda case.

Cheers,
Adam