Closures: Open Issues (v0.5)

• Make it easy to yield a result early from a closure. It should be as easy to yield a result early from a closure as returning from a method.
• Should support for currying be directly in the language? Bound method references?
• Handle interfaces like Comparator that define more than one method, all but one of which will be implemented by a method inherited from Object.
  The definition of "interface with a single method" should count only methods that would not be implemented by a method in Object and should count multiple methods as one if implementing one of them would implement them all. Mainly, this requires a more precise specification of what it means for an interface to have only a single abstract method.
• Specify mapping from function types to interfaces: names, parameters, etc.
  We should fully specify the mapping from function types to system-generated interfaces precisely.
• Type inference. The rules for type inference need to be augmented to accomodate the inference of exception type parameters. Similarly, the subtype relationships used by the closure conversion should be reflected as well.
• VM support for null
  The verifier already supports null, including in the verifiers, but there is no way to specify null as a method argument or return type. We need a way to specify null in a signature (that is, a new signature letter).
• Elided exception type parameters to help retrofit exception transparency.
  Perhaps make elided exception type parameters mean the bound. This enables retrofitting existing generic interfaces that don't have a type parameter for the exception, such as java.util.concurrent.Callable, by adding a new generic exception parameter.
• Document the new unchecked Throwables for nonlocal transfers.
  
• Should javac detect the most common problematic interactions catching nonlocal transfers?
  The most likely case may be completely local within a single method, when a nonlocal transfer has a try-catch between the transfer and its target.
• volatile on locals.
  We should say it is allowed.
• How are class literals for function types formed?
  Is it {?=>?}.class ?
• The system class loader should dynamically generate function type interfaces.
  The interfaces corresponding to function types should be generated on demand by the bootstrap class loader, so they can be shared among all user code. For the prototype, we may have javac generate these interfaces so prototype-generated code can run on stock (JDK5-6) VMs.
• Can or should javac inline some invocations of control abstraction APIs?
  If so, how will it decide which ones? Does the inlining happen at the bytecode or source level? Will javac handle break/return/continue efficiently when these are inlined? Or is this something should be left for the VM to handle? (Hotspot already seems to handle the most important cases)
• Do we need any new reflection support for closures?
  For function types? For null? Probably not because of the information available in the defining (not bridge) methods.
• Should a labelled for control invocation statement interact with labelled break and continue?
• Should for be a modifier (before the return type in a method declaration) or appear next to the name?
• Would explicit VM support for nonlocal transfers improve performance?
• Should we request VM support for proper tail recursion?
• Should we support (parametric) polymorphic function types? Probably not.