问题
I tried to write simple implementation of flatMap for Either
sealed trait Either[+L, +R] {
def flatMap[B](f: R => Either[L, B]): Either[L, B] = this match {
case Left(e) => Left(e)
case Right(e) => f(e)
}
}
final case class Right[+A, +B](right: B) extends Either[A, B]
final case class Left[+A, +B](left: A) extends Either[A, B]
and faced following problem: covariant type L is in contravariant position in type f: R => Either[L, B] of value f, but why is it so? I thought that our type is in contravariant position when we take variant type as an argument for function and it has nothing to do with a type declaration
回答1:
You can think of R => Either[L, B] as a "generalized value of type L" - it's not exactly the same thing as an L, but given an R it might produce an L. So, your flatMap "consumes generalized values of type L". At the same time, your variance declaration claims that Either[+L, +R] is covariant in L, therefore, an Either[VerySpecial, R] would have to be a special case of Either[RatherGeneral, R]. But this is impossible, because the flatMap that can consume only VerySpecial values would choke on a RatherGeneral input.
- In
Either[+L, +R],Lis in covariant position (it "produces"Ls, at least sometimes) - In
R => Either[L, B],Lis still in covariant position (because the function producesEither[L, B], andEither[L, B]in turn producesLs, so the whole thing producesLs) - In
(R => Either[L, B]) => Either[L, B], the firstLappears in contravariant position, because the argument part is consumed by the methodflatMap.
This is easily fixed with the standard lower-type-bounds trick:
sealed trait Either[+L, +R] {
def flatMap[B, M >: L](f: R => Either[M, B]): Either[M, B] = this match {
case Left(e) => Left(e)
case Right(e) => f(e)
}
}
final case class Right[+A, +B](right: B) extends Either[A, B]
final case class Left[+A, +B](left: A) extends Either[A, B]
来源:https://stackoverflow.com/questions/52040427/type-l-is-in-contravariant-position-in-type-a-eitherl-b