问题
Why does the following code work when Foo is invariant, but not when it is covariant? The covariant version of Foo produces a type error saying that in the call of useF1, the argument has type Foo[T] but F1 is required. A similar error is produced for useF2.
If the variance annotation is removed from Foo, the code works. The pattern match against F1 exposes the fact that T = Int, so that x has type Foo[Int]. The implicit conversion function is used to convert Foo[Int] to F1 in the argument of useF1. Similarly for F2. What part of this process is different when Foo is covariant, and why?
// A GADT with two constructors
sealed abstract class Foo[+T]
final case class F1() extends Foo[Int]
final case class F2() extends Foo[Unit]
object Example {
// A Foo[Int] can only be an F1
implicit def refineGADT(x : Foo[Int]) : F1 = x.asInstanceOf[F1]
// A Foo[Unit] can only be an F2
implicit def refineGADT(x : Foo[Unit]) : F2 = x.asInstanceOf[F2]
def useF1(x : F1) = ()
def useF2(x : F2) = ()
def demo[T](x : Foo[T]) = x match {
case F1() => useF1(x) // error
case F2() => useF2(x) // error
}
}
Although GADTs make subtyping more complicated in general, in this case the only two possible concrete types are Foo[Int] and Foo[Unit], and no subtyping relationship holds between them, so subtyping shouldn't affect this example.
回答1:
You just have to rebind the matched F1 or F2 in demo:
def demo[T](x : Foo[T]) = x match {
case y@F1() => useF1(y)
case y@F2() => useF2(y)
}
x is of type Foo[T] so the compiler can't deduce that it is valid input for useF1. When T is invariant, the compiler can deduce a little bit more and is able to resolve this case. When T is covariant, we know that it is valid in the matched case, but we have to bind a new identifier to help the compiler. You can even bind the matched classes to x to shadow the outer x (e.g. case x@F1()), but then you lose the ability to reference the outer x if you need to.
回答2:
First, let's simplify your example (assuming we ignore type erasure):
class Foo[+T]
def demo[T](x : Foo[T]) = x match {
case _: Foo[Int] => x: Foo[Int] //error but works with `class Foo[T]`
case _: Foo[Unit] => x: Foo[Unit] //error but works with `class Foo[T]`
}
Or even:
class Foo[T]
scala> def demo[T](x : Foo[T]) = x match {case _: Foo[Int] => x}
demo: [T](x: Foo[T])Foo[Int] //notice Int
class Foo[+T]
scala> def demo[T](x : Foo[T]) = x match {case _: Foo[Int] => x}
demo: [T](x: Foo[T])Foo[T] //notice T
Expected type of x as expression is the existential type Foo[_ >: T] (as a result of covariance applied to the return type), or more precisely Foo[X >: T] forSome{type X}. So compiler can't process it as this feature or bug (typecast in context of matching) doesn't work for existential types as it can't prove that Foo[Int] always belongs to R, where R :> Foo[X] for some X >: Int. So R may be :> Foo[Int] or may be :> Foo[Any] or something else :> Foo[_ :> Int], which makes R a coproduct of possible ranges. Such coproduct can't be cast to Foo[Int]:
class Foo[T]
def demo(x : Foo[_]) = x match {
case _: Foo[Int] => x: Foo[Int] //error
case _: Foo[Unit] => x: Foo[Unit] //error
}
<console>:9: error: type mismatch;
found : Foo[_$1] where type _$1
required: Foo[Int]
case a: Foo[Int] => x: Foo[Int] //error
^
^
<console>:10: error: type mismatch;
found : Foo[_$1] where type _$1
required: Foo[Unit]
case a: Foo[Unit] => x: Foo[Unit] //error
^
P.S. Example about how covariance relates to existentiality:
scala> class Foo[T]
defined class Foo
scala> def demo[T](x : Foo[T]) = (x: Foo[_ >: Int]) //can't cast to something in Int..Any range
<console>:17: error: type mismatch;
found : Foo[T]
required: Foo[_ >: Int]
Note: T <: Any, but class Foo is invariant in type T.
You may wish to define T as +T instead. (SLS 4.5)
def demo[T](x : Foo[T]) = (x: Foo[_ >: Int])
^
scala> class Foo[+T]
defined class Foo
scala> def demo[T](x : Foo[T]) = (x: Foo[_ >: Int])
demo: [T](x: Foo[T])Foo[Any]
来源:https://stackoverflow.com/questions/29426378/implicit-resolution-with-covariance