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