C++11 lambdas
Reinier Zwitserloot
reinier at zwitserloot.com
Mon Mar 15 15:11:20 PDT 2010
On Mon, Mar 15, 2010 at 11:08 PM, Rémi Forax <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. 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. 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 also see # as a visual clutter.
>
>
Given that closures aren't in java today, and given that the way closures
are going, what with the function types, it's not going to be completely
integrated into all existing java code, probably _ever_, the notion that
closures are as common as, let's say, int literals, doesn't sound right.
Therefore, no, it's not visual clutter. Either way, with the 'visual
clutter', the compiler will continue to emit sensible error messages.
Without it, a sizable set of commonly emitted error messages are going to
lose clarifying power, due to the extreme similarities between closure
declarations, function type references, and existing legal java code
constructs.
More information about the lambda-dev
mailing list