Function types versus arrays

[Joshua Bloch]

I just assumed that we'd do whatever it takes to make this works, up to and
including VM changes. At least we don't have the migration compatibility
issues that we had with generics. If arrays of functions don't work,
functions are a second-class type family. That arrays and generics don't
play nicely together is a major pain in the butt. I really would prefer not
to see this repeated. I understand the difficulties in making this work but
(as I keep saying) we shouldn't give up without a fight. Much as some of us
consider arrays to be denigrated in favor of List<E>, they are still *widely
*used, even in new code. If arrays of function types aren't supported,
people will complain. And they may rightly accuse us of doing what was easy
to implement rather than what is easy to use.

    Regards from Cape Canaveral,

    Josh

On Mon, Feb 8, 2010 at 2:30 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:

> Neal raises a fair point. I recognize that arrays of function types are
> as potentially unsafe at runtime as arrays of non-wildcard parameterized
> types.
>
> And this is the same problem one sees when passing variables of
> parameterized types as varargs parameters. The varargs method body can
> silently do unsafe things, thanks to Object being a universal supertype.
>
> Banning arrays of function types is an option. It somewhat conflicts
> with Project Coin's promotion of [] syntax to read/write collections.
>
> I am interested in people's thoughts on the limitations of arrays of
> parameterized types. (Reification was not and is not an option, so
> please no ranting about the stupid implications of erasure.) Does anyone
> care about arrays anymore?
>
> Alex
>
> Rémi Forax wrote:
> > Le 07/02/2010 19:41, Neal Gafter a écrit :
> >> I've been asked if arrays and function types will play nicely
> >> together.  Specifically, for example, whether or not something like
> >> the following will be allowed:
> >>
> >> #String(String)[] arrayOfFunction = new #String(String)[10];
> >>
> >> The current draft spec, by the absence of any constraining rules,
> >> implies yes.  But if I have to guess, I would say the end result of
> >> project lambda will probably say no.  Although we haven't talked much
> >> about implementation techniques, I'm not aware of any proposed
> >> implementation technique that would allow this without opening a hole
> >> in the type system.
> >>
> >> I don't know whether we should consider this important or not (I
> >> don't; I'm perfectly happy using java.util.List), but if it is
> >> important then someone should be thinking about what needs to happen
> >> (VM support?) to make it work.
> >>
> >
> > For the record the problem is:
> >
> > #String(String)[] arrayOfFunction = new #String(String)[10];
> > Object[] array = arrayOfFunction;
> > array[0] = #int() (2);
> >
> > The last line should raise an array store exception.
> > So the VM should be aware of the precise type of the array of function.
> >
> > Currently, neither the anonymous class translation nor the method handle
> one
> > provide reified function type so array of function types are unsafe.
> >
> > Because function type doesn't exist in the language, I propose to make
> > the syntax
> > for an array of function type (#String(String)[]) illegal.
> >
> > I'm also happy with List, perhaps we should introduce a new interface
> > ReadOnlyList
> > which is a super type of List and array of objects but that another
> story.
> >
> >> Cheers,
> >> Neal
> >>
> >
> > Rémi
> >
>
>