Function types versus arrays

[Joshua Bloch]

On Wed, Feb 17, 2010 at 2:48 PM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Feb 17, 2010 at 2:39 PM, Joshua Bloch <jjb at google.com> wrote:
> > Neal,
> > I'm having a bit of trouble understanding this.  I'm not endorsing any
> > implementation scheme, but you say that this program necessarily breaks
> the
> > type system:
> >
> > public void main(String[] args) {
> >     #void()[] arrayOfFunction = new #void()[1];
> >     Object[] objectArray = arrayOfFunction;
> >     objectArray[0] = #(){ throw new IOException(); };  // **
> >     arrayOfFunction[0].(); // invoke the function out of the array
> > }
> >
> > It would appear that the starred line should generate an
> ArrayStoreException
> > at runtime, as #void()(throws IOException) isn't a subtype of #void().  I
> > understand that it might take a sophisticated implementation to enforce
> > this. What am I missing?
> >          Josh
>
> Presuming the source were legal, that's exactly right.  We're
> exploring how such a "sophisticated implementation" breaks
> compatibility with the existing language specification (thus the
> "implementation" focus of the discussion), with the consequence that
> the source must not be allowed.
>

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.

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).

              Josh