Function types versus arrays

[Peter Levart]

On Friday 12 February 2010 00:26:59 Neal Gafter wrote:
> On Thu, Feb 11, 2010 at 3:06 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> >> The current draft spec, by the absence of any constraining rules,
> >> implies yes.
> >
> > Finishing up here for now, the 0.1 draft spec doesn't fully imply "yes".
> >
> > - It implicitly allows, and will continue to allow, an array type whose
> > element type is a function type.
> 
> Given that there is no way to create a value of such a type (or a
> value of a subtype of such a type), other than null, what value is
> there in allowing it?  Why would you commit yourself now to that
> position for future revisions of the spec?
> 
> 

In analogy with parameterized types I propose a notation for "raw" function types. For example:

  // produces unchecked assignment warning
  #String(String,String)[] a1 = new #?(?,?)[] { #(String s1, String s2)(s1+"_"+s2) };

Primitive returns/parameters can be mixed into "raw" function type to produce a "mixed raw/primitive" function type:

  // produces unchecked assignment warning
  #int(String)[] a2 = new #int(?)[] { #(String s)(s.length()) };

What to do with throws types? Treat them the same as a return type?

  // produces unchecked assignment warning
  #String(File)(throws IOException)[] a3 = new #?(?)(throws ?)[] { };


With this scheme, there is a straightforward mapping to parameterized interfaces.

Regards, Peter