Make Eval covariant in its type parameter

[alexandru]

So I enthusiastically started using Eval, but then noticed that Eval[A] is not covariant in A and this creates problems for me.

Now I understand that variance is a hard and I understand why type-classes are invariant and so on, but Eval is supposed to be a replacement for by-name and for Function0[+R] parameters and the problem is that functions in Scala are covariant in their return, along with most immutable data-structures from the standard library. And so when you want covariance, then Eval ends up not being a replacement for by-name parameters.

My use-case is the ability to use F[Nothing] for empty containers when it comes to things like this:

trait Sequence[+A] {
  def continueWith[B >: A](other: => Sequence[B]): Sequence[B]
}

In the above, the ability to pass in a Sequence[Nothing] sure comes in handy. And replacing that parameter with an Eval doesn't work as well as it does with a by-name parameter.

Link to the Gitter conversation: https://gitter.im/typelevel/cats?at=56e95650c7364f7926bf7d38

[non]

So, I'm cautiously 👍 on this proposal. I agree that the purpose of Eval[A] is to abstract over => A, and so it should work for the same purposes. That said, there are definitely some contexts where variance causes real problems, so I think we should proceed a little bit carefully.

I tested a one-character change today (Eval[A] => Eval[+A]) and everything compiled, tests pass, etc. So at least as far as Cats goes this is not a big change.

[non]

Also -- nothing is set in stone until 1.0, so we could always turn this on and keep an eye out for problems in the next few months.

[milessabin]

👍

[ceedubs]

Just to summarize what I've said on Gitter:

I'm okay either way on this one. Variance can be very problematic in some contexts (two that come to mind are on type classes and on abstract type constructor parameters). However, in this case, sealed abstract class Eval[+A] would look a lot like sealed abstract class Option[+A] or sealed abstract class List[+A] from a compiler perspective. While there are some minor annoyances with List and Option being covariant, I don't think it's ever caused serious issue, and there are some definite benefits.

Since there's been a lot of discussion around this, I propose that we keep this issue open for 2 weeks and reassess at that point. If people still seem to generally be in favor of this and nobody has provided a show-stopping example of how it could be problematic, let's go for it.

[edmundnoble]

Would anybody be interested in a typeclass encoding of variance and covariance? The laws would likely require asInstanceOf and isInstanceOf to state, if we went that path. I have something like this on my fork:

  @typeclass trait Co[F[_]] {
    def widen[A, B >: A](fa: F[A]): F[B]
  }

  @typeclass trait Contra[F[_]] {
    def specify[B, A >: B](fa: F[A]): F[B]
  }

Functor would extend Variance.Co and Contravariant would extend Variance.Contra. Might this avoid some of the problems of variance but still allow ease of use? I'm not sure which typeclasses are naturally covariant or contravariant other than Functor and Contravariant; if none are, these methods could just be included in Functor and Contravariant, like they are in Scalaz.

[adelbertc]

@edmundnoble I would prefer putting them on Functor and Contravariant

[ceedubs]

@edmundnoble I've thought several times about adding those methods to Functor and Contravariant. The thing that keeps holding me up is that I start asking myself whether we could potentially run into any issues if we just use asInstanceOf instead of the more correct but less performant map(identity).

This probably becomes less of an issue when we address #168 (comment) which we are planning on doing before a 1.0 release.

[ceedubs]

Resolved in #937.