如果我们已经有类型边界，为什么我们需要变化？

Question

If I write Foo[_ <: Bar] or Foo[+T <: Bar] what does the latter let me do, that I could not do with the former?

Is it just convenience, so that can write def bar: T rather than def bar: Bar ?

In which context is it useful?

Is it actually accurate to say that there is no variance in java? Can one not model it with <? extends Foo> <? extends Foo> and <? super Bar> <? super Bar> ?

Answer 1

The type bounds control what types are valid parameters. The covariance/contravariance annotations control the sub/super-typing relationship between instances with different parameters. Foo[+T] means Foo[A] is a subtype of Foo[B] if A is a subtype of B . Foo[-T] means the reverse.

class Foo1[T <: Bar]()
class Foo2[+T <: Bar]()
trait Bar
trait Baz extends Bar

val f1: Foo1[Bar] = new Foo1[Baz]() // compile error
val f2: Foo2[Bar] = new Foo2[Baz]() // works just fine

One benefit as opposed to using type boundaries like Foo1[_ <: Bar] everywhere is the compiler will enforce certain properties on the class itself. For instance, this won't compile:

class Foo[+T]() {
  def f(t: T): Unit = {}
}

Neither will this:

class Foo[-T]() {
  def f(): T = { ??? }
}

As far as I know, Java has no way to explicitly represent covariance or contravariance. This has led to a lot of bugs, especially with arrays being implicitly covariant even though they shouldn't be since they are mutable.

Answer 2

Is it actually accurate to say that there is no variance in java? Can one not model it with <? extends Foo> <? extends Foo> and <? super Bar> <? super Bar> ?

Java is usually said to have use-site variance, as opposed to Scala declaration-site variance (well, really Scala supports both). It is actually more expressive, strictly speaking: you can write more sensible programs, eg methods which don't put anything into a List may be covariant while methods which put but don't look at the contents may be contravariant. With declaration-site variance you instead need to have separate immutable and mutable types.

A well-known symptom of the problem is the signature of Set#contains in Scala, which can't just accept A without forcing Set to be invariant.

The problem with having only use-site variance is that it complicates the signatures of all methods working with the type if you want to be consistent: not just the ones declared on the type itself, but those which call them.

See also How does Java's use-site variance compare to C#'s declaration site variance? and https://kotlinlang.org/docs/reference/generics.html#variance .