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