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
