Expression syntax

Zdenek Tronicek tronicek at fel.cvut.cz
Thu Nov 19 09:00:04 PST 2009


Sorry, of course should be:

> #int(T) p = #(T t) t.m();  // expression lambda
> #int(T) p = #(T t) { return t.m(); }  // statement lambda

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Cituji Zdenek Tronicek <tronicek at fel.cvut.cz>:

> Hi Paul,
>
> I am not Neal nor Remi but I will try to answer anyway :).
>
> Braces are not optional here because they distinguish between  
> expression and statement lambda:
>
> #int(T) p = #(T t) t.m();  // expression lambda
> #int(T) p = #(T t) { return t.m(); }  // expression statement
>
> I think this is a good choice because previous syntax (when the  
> closure returns the value of the last expression) was confusing.
>
> Zdenek
> -- 
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Cituji Paul Benedict <pbenedict at apache.org>:
>
>> Neal/Remi, perhaps you could give your opinion on this one. To me,
>> having well-formatted code to make easy readability is important to
>> me. It's very important. I don't find it very readable without the use
>> of braces to enclose the lambda function.
>>
>> Example:
>> #int(String) fun = #(String text) text.length();
>>
>> If braces aren't mandatory, are they validly optional? I would rather write:
>> #int(String) fun = #(String text) { text.length(); }
>>
>> And that could allow my IDE formatters to run their rules based on how
>> to handle braces. If someone likes breaking, this can remain possible:
>> #int(String) fun = #(String text) {
>>   text.length();
>> }
>>
>> If someone likes to inline everything, this could be possible too:
>> object.call(a, b, c, #(String text) { text.length(); });
>>
>> Just to be clear, my focus here is on flexibility to take advantage of
>> existing IDE formatting options surrounding braces.
>>
>> Paul
>>
>
>
>
>





More information about the closures-dev mailing list