Removal of function types

Brian Goetz brian.goetz at
Wed Jul 7 11:16:00 PDT 2010

> The latest (6 July) lambda document removes function types. I support
> this (even though they were in FCM).

Indeed it does.  People will ask why, so let me share my thinking here.  Among 
other reasons:

1.  There are two basic approaches to typing: nominal and structural.  The 
identity of a nominal is based on its name; the identity of a structural type 
is based on what it is composed of (such as "tuple of int, int" or "function 
from int to float".)

Most languages pick mostly nominal or mostly structural; there are not a lot 
of languages that successfully mix nominal and structural typing except 
"around the edges."  Java is almost entirely nominal (with a few exceptions: 
arrays are a structural type, but at the bottom there is always a nominal 
element type; generics have a mix of nominal and structural too, and this is 
in fact part of the source of many of people's complaints about generics.)

Grafting a structural type system (function types) onto Java's nominal type 
system means new complexity and edge cases.  Is the benefit of function types 
worth this?

2.  We've been using SAM types for years, and Java developers are comfortable 
with them.  If we added function types, it would immediately bifurcate the 
libraries (both JDK and external) into "old style" libraries (those that use 
SAM types) and "new style" libraries (those that use function types.)  That's 
a big ugly seam in the middle of the platform.

3.  No reification.  There was a long thread about how useful it would be for 
function types to be reified.  Without reification, function types are hobbled.

For these reasons and others, we would prefer to leave out function types now.

> - Removing them reduces the scope, thus increasing the delivery likelihood
> - Function types look pig ugly with exception transparancy
> - Function types are a very different concept to the rest of Java,
> which is very name based
> - Function type don't visually look much like types (which are names
> everywhere else)
> - SAMs centralise the definition of Javadoc and give a meaningful name
> - function types don't
> - Function types were causing trouble when in a list/array due to
> generic erasure
> - Removing them removes some of the most contentious syntax debates
> - Function types can be added later if the right approach is taken (as
> in the doc) of declaring lambda expressions to have no expressible
> type.
> I suggest using this thread to comment on the removal of function types :-)
> Stephen

More information about the lambda-dev mailing list