call operator and orthogonality with existing VM internals

[Neal Gafter]

Jakob-

What you're describing is called declaration-site variance (as opposed
to wildcards, which are use-site variance).  It has been brought up
before both for project coin and project lambda, and in both cases was
declared outside of the scope of the projects.

Cheers,
Neal

On Tue, Mar 9, 2010 at 3:22 PM, Jakob Praher <jp at hapra.at> wrote:
> Neal Gafter wrote:
>> On Tue, Mar 9, 2010 at 9:24 AM, Jakob Praher <jp at hapra.at> wrote:
>>
>> Which is why BGGA provides a special syntax for function types that
>> inserts the wildcards for you.
>>
>>
> When talking about Java on the whole (not the feature of adding function
> types), it might make sense to add support for covariant/contravariant
> annotations on types? Maybe it is enough to be able to use wildcards
> inside interface defintions:
>
> For instance
>   interface Function1<? extends R,? super T1> { ... }
> would just mean that every usage of Function1<R,T> is replaced by
> Function1<? extends R, ? super T1>. The wildcards are stored in the type
> itself. It might not make sense to you to use exactly wildcards in the
> type definition this way, but I did not want to introduce a new syntax.
>
> This checks are done by the compiler (due to type erasure). There might
> be a better way to express this yet other than that the implementation
> could be done. Given that throws had to be added if the BGGA route would
> be taken (no?), was there any compelling reason not to consider variance
> qulifiers in type declarations? IMHO the big plus is that interface
> types are concise again. And the feature could be used in general. I
> also see no difference if every type of a function is automatically
> translated to have wildcards.
>
> And if I may add wildcards arbitrarily in type declarations I do not
> think it is dangerous to declare them generically in the type definition.
>
> Scala takes a similar route and allows variance annotations on generic
> types. There are some additional checks such that the type declaring the
> annotations must conform to covariance and contravariance. See chapter 4
> section 5 of the Scala Language Specification [1].
>
> -- Jakob
>
> [1] -
> http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf
>