C++11 lambdas
Rémi Forax
forax at univ-mlv.fr
Mon Mar 15 15:47:36 PDT 2010
Le 15/03/2010 23:11, Reinier Zwitserloot a écrit :
> On Mon, Mar 15, 2010 at 11:08 PM, Rémi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>
> I don't follow you.
> What is the error the compiler should output ?
>
>
>
> Exactly. It's not clear anymore.
The Java grammar already allows some common prefix for expressions and
types.
What is the error message for:
(a<b,c;
knowing that (a<b,c>) is a cast and (a<b,c) is an expression.
I suppose the error message is something like 'syntax error' so
I continue to don't see your point here.
> Hence the compiler can choose to either emit one error, which means it
> generates something very confusing in 50% of the cases, or, it can
> choose to emit a rambling error that lists all the possible causes.
> That was the point: This is a bad thing. With the # the intent is more
> clear, which leads to better error messaging. As far as the compiler
> is concerned, no #, no closure.
Remember that from the strawman proposal you can find # in a function type,
a lambda or a method reference.
What is your proposed error message for a ill-formed snippet like this:
#()int
my guess is 'syntax error'.
> The same thing happens right now in for example class declarations. If
> you don't include a class declaration indicator ('class', 'interface',
> or 'enum') both ecj and javac do not consider it a (botched) type
> declaration.
You can always improve error recovery knowing that both ecj and javac
use hand written
error recovery rules.
Rémi
More information about the lambda-dev
mailing list