Are function types a requirement?

[Alex Buckley]

Reinier Zwitserloot wrote:
> On a different note, generified varargs are legal. You just get a warning.

This is effectively incorrect.

A varargs formal parameter that is parameterized ought to be illegal. 
(At least where varargs are implemented with arrays.)

It breaks the property that static type correctness implies dynamic type 
safety. We allow such a parameter only for convenience. A warning 
indicates that you are being allowed to hang yourself for your own 
convenience. The word "just" has no place here.

What you propose below (and it's really very clever) is to strengthen 
the static type system in the body of a varargs method. Your rules are 
so strong that if the body is statically type correct, then it will be 
dynamically type safe. You have achieved this by basically banning any 
language construct whose static typechecking involves subtype rules. For 
example, aliasing the varargs formal parameter through an Object[] - the 
usual way to lose dynamic type safety - is banned in your static type 
system, and code that did it would cause a warning.

I discussed restrictions of this kind extensively with Josh Bloch and 
Bob Lee before Bob's Coin proposal. The summary is that I'm not a fan, 
which is why the proposal doesn't change the static type system and thus 
requires a very strong programmer declaration that the method body will 
be dynamically type safe promise promise promise.

(Strictly speaking, I'm not a fan of building this alternative static 
type system *on top of array-based varargs*. You get your strong static 
typechecking for free with covariant generics. That is, if a varargs 
formal parameter of type Foo<String>... was translated to List<? extends 
Foo<String>>, the method body would be suitably restricted. Redefining 
varargs in this way is not in scope for Project Lambda.)

All the above applies whether the varargs formal parameter is a 
parameterized type or a function type. Neither kind of type is going to 
be reified in the near future.

Alex

> However, that warning is moving to the target method (it's one of project
> coin's features). I proposed at the time that this warning too can be
> eliminated if the following holds:
> 
> The array variable is only read from, iterated over (foreach), or a
> method/field access (.length, .toString()) done on it.
> 
> Or, to be more specific:
> 
>  1. The array variable is not used in any expression, even as a primitive
> (Object o = varargsParam;), except for:
> 
>  1A. LHS of a method invocation, so, varargsParam.toString() is acceptable
> (not much use in doing it, but it won't cause the warning).
> 
>  1B. LHS of a field access, so, varargsParam.length is okay.
> 
>  1C. Used as a primitive expression as the iterable in a foreach, so, for (T
> x : varargsParam) is okay.
> 
>  2. array assignment to the varargsParam does not occur. So,
> varargsParam[expr] = whatever; means the warning appears.
> 
> 
> If the varargs method adheres to all these rules, then the warning is not
> shown. None of this seems prohibitive to scan for (none of it requires type
> resolution, for example), it's sufficient for type failures due to lack of
> reification to be impossible, and (guesstimating) it'll cover 99%+ of all
> uses of varargs out there.