Are function types a requirement?

[Stephen Colebourne]

Recent threads have indicated the difficulties of adding function types 
to the language.

- difficult/impossible to integrate with arrays (an omission that would 
certainly be a surprise to many I suspect)

- difficult to integrate with varargs

- difficult to implement (various strategies suggested)

- difficult syntax choices (difficult to find something that is easy to 
read, given Java's painful checked exceptions)

- debated invocation syntax - the func.() syntax


One alternative is to omit function types from JDK 7, and only include 
conversion to SAM interface types. It would be a compile time error to 
declare a lambda expression/block that did not convert to a SAM.

Function types could then be included in JDK 8 if a valid approach was 
available (ie. it gives the appearance of needing much more in depth 
study than the timescale allows)

Pros:
- reduces risk of making the wrong decision in the short JDK 7 time-frame

- avoids all the issues above (AFAIK)

- doesn't restrict adding function types later (we'd need some proof of 
this)

- reduces the initial learning curve

Cons:
- doesn't tackle the problem of fork-joins excess of interfaces, which 
is declared as a major project goal

- results in multiple, incompatible SAM interfaces for the same concept

- no automatic handling of co/contra variance


I therefore ask (in a positive way!) as to whether function types are a 
fixed requirement of project lambda? Or whether the SAM-conversion-only 
strategy would be considered for JDK 7? (My concern is to avoid the 
experience of generic wildcards where it was rather rushed in at the 
last minute by all accounts)

I'm really looking for a simple answer from Alex rather than a debate on 
this...

Stephen