Function types versus arrays

[Neal Gafter]

On Wed, Feb 17, 2010 at 2:59 PM, Joshua Bloch <jjb at google.com> wrote:
> I really don't understand this.  Earlier on, Alex said that we should
> refrain from thinking too hard about the implementation at this point, and I
> still believe that to be true.  If you could show that some interaction of
> the proposed syntax and semantics interacted poorly with the existing type
> system, that would be a big problem, but I haven't seen such an argument
> that didn't presuppose a particular implementation of function types. I
> really do think we should design the best spec (syntax and semantics) and
> then see if it's implementable.

I agree with the process you describe.  I just think we're a couple of
steps ahead of you.  Setting aside the precise syntax, there is a
specific problematic interaction of the currently proposed semantics
with the existing type system, and we're exploring the fallout of that
issue.  We don't have to wait for the syntax to be settled to explore
the fallout of the semantics issue, and as I pointed out resolving the
semantic issue can help guide the syntax.

> Earlier, I suggested that we should allow arrays of function types if we
> can.  \Otherwise, we're damning function types to life as second-class
> citizens of the Java type system. We're also screwing up variable-arity
> function typed args, as varargs is a leaky abstraction built atop arrays.
>  This isn't a theoretical concern; it impacts reasonable programs. For
> example, consider a method that takes a bunch of #int(int) functions and
> returns their composition:
>     #int(int) compose(#int(int)... fns) {  <implementation> }
> This should definitely be legal, and shouldn't generate a warning
> (especially given that we're providing a means to eliminate this sort of
> warning on generic varargs parameters in Java 7).

This is all true, but the facts of the universe we live in have
conspired against us.  We should if we can, but we can't.  All of the
good reasons for the "should"s don't reduce the impact of those facts;
we have to face them and design the best feature we can given the
constraints of the real world.