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? That seems
necessary to support non-trivial lambda bodies; otherwise we won't be
able to handle dependence properly.
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.
Jason
