In a recent blog post, What's so Taxing about Return?, Cay Horstmann explains that programming languages treat the concept of return differently, with some languages not even having constructs that are equivalent to Java's return statement. While Java's return has been a well-understood concept, the meaning of return can become complicated in the context of the various proposals to add closures to Java, according to Horstmann.

A closure is a block of code, packaged up for execution at a later point. When it executes, all the references to the surrounding code should just work as if the code had executed in the defining scope...

A closure returns a value (if it has a result type). For example,

{ int x, int y => Math.max(x, y) }

returns an integer, the max of its parameters. But if a closure contains a return statement, that means to return from the enclosing block. For example,

{ int x, int y => return Math.max(x, y); }

is a closure with return type void that, when invoked, causes its caller to return the max of the parameters (or, presumably, if the caller can't return an int, throw an exception)... Several commentators to my earlier blog point to this issue as the Achilles heel of the BGGA proposal...

Ultimately, the culprit is the dual nature of return: yielding a value, and jumping to the end of the method code. In Pascal or Scheme, none of this is an issue. These languages have no return (or break or continue) to worry about.

Horstmann notes that the problem also stems from the fact that developers can use closures both as control structures and as a form of callback:

When one uses a closure for a control abstraction, the return type must be void since the closure denotes a statement. And it is pretty clear that return means to return from the enclosing scope.

When one uses a closure as a callback, to be invoked at a much later time, does one ever want to capture the enclosing semantics of return? I don't think so, but I will find out soon enough if I am wrong... It would make sense to differentiate these use cases.

Those opposing the introduction of closures to Java often cite the increasing complexity that closures would bring to the language. While closures in other languages, such as Ruby, have found their natural expression, and few developers seem to be confused by them, Horstmann's post shows that closures can in some cases make the meaning of code ambiguous.

Do you support adding closures to Java? Do you believe developers will find the best use-cases for closures without getting confused by the double role closures can play in Java?

    List<String> foo = ...
    Collections.sort( foo, new Comparator<String>() {
      public int compare( String o1, String o2 ) {
        return o1.compareTo( o2 );
      }
    } );

     declare foo = ...
     Collections.sort foo, method( o1, o2 ) { o1.compareTo( o2 ) } );

    List<String> foo = ...
    Collections.sort( foo, new Comparator<String>() {
      public int compare( String o1, String o2 ) {
        return o1.length() - o2.length();
      }
    } );
 

  foo.sortBy( \ str -> str.length() )
 

  closure = '\' arg_list '->' closure_body
  closure_body = expression | '{' statement_list '}'