C++11 lambdas
Rémi Forax
forax at univ-mlv.fr
Mon Mar 15 15:08:14 PDT 2010
Le 15/03/2010 21:33, Reinier Zwitserloot a écrit :
> Once you add enough delimiters to eliminate all ambiguity in this
> syntax, Remi, you'll arrive pretty much at the closure proposal that's
> the status quo right now.
I don't think so :)
>
> For example, your syntax cannot differentiate between multiple
> exceptions and a listing of types:
>
> void(int() throws Exception1, Exception2)
>
> Is this:
>
> A) a function type that returns nothing and takes 1 parameter: int()
> throws Exception1, Exception2
>
> B) a function type that returns nothing and takes 2 parameters: int()
> throws Exception1, as well as parameter of type Exception2?
Exceptions are separated by pipes.
>
> Second example:
>
>
> int();
>
> Is this:
>
> A) A syntax error: A function type representing a return type of int
> with no arguments, by itself and thus invalid?
>
> B) A syntax error: The invocation of a method named 'int', which is
> not valid because 'int' is a reserved keyword?
>
>
> What error should the compiler generate? Can you tell what was
> intended? Vague error messages or error messages that don't do a good
> job of explaining what you did wrong is something that java doesn't
> have that much trouble with compared to for example Scala. It's a
> significant cost to bear if this means the compiler starts generating
> confusing, vacuous, or downright wrong error messages.
I don't follow you.
What is the error the compiler should output ?
>
>
>
> I wrote down a few more examples, and anytime I made even a single
> change to some syntax, the meaning became _completely_ different. A
> far too heavy price, in my opinion. I actually like the # as a clear
> visual signal that there's a closure definition around.
You can also see # as a visual clutter.
>
> --Reinier Zwitserloot
Rémi
More information about the lambda-dev
mailing list