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