Alternative syntax for closures (original) (raw)
Neal Gafter neal at gafter.com
Mon Jul 7 00:07:16 PDT 2008
- Previous message: jsr166y.forkjoin vs closures - ambiguous method reference
- Next message: Alternative syntax for closures
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
One idea we tossed around a few months ago, without any real conclusion, was to replace the curly braces with parens. Things have changed a bit since then; I'd now use a dash-greater instead of equals-greater. I think we could consider using the parens for restricted closures (for those of you who haven't been paying attention, restricted closures can't use return, break, or continue to a target outside the closure) and curly braces for the unrestricted form.
RestrictedLambdaExpression ( FormalParameterDecls**opt —> BlockStatementsopt Expressionopt** ) RestrictedFunctionType ( TypeList**opt —> Type ThrowsClause**opt )
UnrestrictedLambdaExpression { FormalParameterDecls**opt —> BlockStatementsopt Expressionopt** } UnrestrictedFunctionType { TypeList**opt —> Type ThrowsClause**opt }
For example (this is not intended to be a motivational example):
- (int, int —> int) plus = (int x, int y —> x+y);* { Answer —> void } block = { Answer answer —> System.out.println(answer); };
The parens instead of curly braces emphasize to the reader that it is an expression closure, which is one of the principal use cases for the restricted form.
Without an active working group, I don't expect to make any major syntax changes in the prototype, but I wanted to get this out there for you to think about.
Regards, Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080707/c6cd9a22/attachment.html
- Previous message: jsr166y.forkjoin vs closures - ambiguous method reference
- Next message: Alternative syntax for closures
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]