C++11 lambdas

[Reinier Zwitserloot]

On Mon, Mar 15, 2010 at 11:47 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> What is the error message for:
> (a<b,c;
> knowing that (a<b,c>) is a cast and (a<b,c) is an expression.
>
>
The error would obviously be that the < is unmatched, and once you solve
that, that the ( is unmatched. FWIW, yes, casts are a source of confusing
error messages. Just because java already has a few of these scenarios
doesn't excuse a new proposal from worrying about them. On the contrary, the
more such confusing scenarios java has, the more important it is that new
ones aren't introduced.


> I suppose the error message is something like 'syntax error' so
> I continue to don't see your point here.
>

Try it. Java doesn't generate unqualified Syntax Errors. That's one of the
many things that makes javac a bit different from new experiments like
haskell or scala*, which pretty much bite your head off with an utterly
confusing error message that probably doesn't even point at the proper
location when you write a syntax error in your code.


> Remember that from the strawman proposal you can find # in a function type,
> a lambda or a method reference.
>

I don't think the strawman had method references. I didn't think the current
status quo proposal does, either. It's either in a function type (something
I've been championing to eliminate, as being unnecessary), or in a lambda,
which are highly related.



> What is your proposed error message for a ill-formed snippet like this:
> #()int
>
> my guess is 'syntax error'.
>
>
Not an acceptable error message.


You can always improve error recovery knowing that both ecj and javac use
> hand written
> error recovery rules.
>
>
Yes. Up to a point. Once a human can no longer tell what you were trying to
do, it's pretty clear a compiler doesn't stand a snowball's chance to do any
better, and in the case of something like "int();" I certainly can't tell if
that's a botched attempt to call a method named 'int', or a dangling
function type.