问题
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