Re: [FIXED] Generic lambda symbol table bug

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

On 07.08.2013 16:59, Jason Merrill wrote:
> On 08/07/2013 03:52 AM, Adam Butcher wrote:
> > But a cleaner way might be to extend the "processing
> > template declaration" state from lambda declarator all the way to 
> > the end of the
> > lambda body.  This would match with the scenario that occurs with a 
> > standard
> > in-class member function template definition.  To do that elegantly 
> > would
> > require a bit of refactoring of the lambda parser code.
>
> It isn't already set through the whole lambda body?
No.  It is within cp_parser_lambda_declarator_opt.

> That seems
> necessary to support non-trivial lambda bodies; otherwise we won't be
> able to handle dependence properly.
Agreed.  Okay, I will produce three patches:

  1) Refactor existing monomorphic implementation to give a cleaner
     parser separation of concerns; extract the fco creation and
     provide begin and end for the lambda function operator.

  2) Add explicit lambda template support.

  3) Add implicit function template support.

> > I'm not sure which dialect guards to put these features behind 
> > though.
> > Strictly:
> >
> >   a) Generic lambdas created fully implicitly via 'auto params' 
> > should be
> >      accepted with -std=c++1y and -std=gnu++1y since it is actually 
> > spec'd by
> >      the draft.
> >
> >   b) Generic lambdas created with an explicit template parameter 
> > list should be
> >      accepted with -std=gnu++1y only.
> >
> >   c) Generalized implicit function templates should be accepted by 
> > -std=gnu++1y
> >      only.
>
> This makes sense to me.  Or perhaps add (c) to the concepts lite
> flag, when there is one.
Okay.  Will do as originally suggested.  I am intending to try out
constrained implicit function templates on the c++-concepts branch
at some point also (which might already have such a flag).

Cheers,
Adam