Function types versus arrays

[Neal Gafter]

On Wed, Feb 17, 2010 at 5:59 PM, Joshua Bloch <jjb at google.com> wrote:
> Can you provide a concise proof that it would require reifying generics?  It
> isn't obvious (to me).

Sure.  If you need more formality, I can work on it this weekend.  One
form of proof goes something like this:

Consider some an existing generic method.  We assume that the existing
callers of this method do not pass enough information for the body of
the method to know, at runtime, the actual types of the type
parameters.  (If needed, I can prove this assumption.)  Now add a
lambda expression inside the body of the method, with the type
parameter appearing in its signature.  The JLS says that changes to
the body of a method are binary compatible.  If function types are
reified, then the type of this lambda expression is available at
runtime.  But that contradicts our assumption that existing callers of
the method do not pass enough information to reify the type parameter.

You might imagine addressing this by disallowing lambdas with type
parameters in their signature, but this would prevent lots of code
(for example, the parallel arrays implementation) from using lambdas.
Lambda expressions are the only way to create values of function type;
anonymous inner classes are not an implementation alternative.
Therefore, the restriction would prevent the parallel arrays API from
using function types.

-Neal