data.Xor and instances/either.scala: Either is now right-biased

[soc]

Either has become right-biased in Scala 2.12, so I think it would make sense to

• check whether instances/either.scala can be cleaned up/stream-lined
• consider whether keeping Xor has benefits that are greater than converging on a single Either implementation in the Scala ecosystem

[adelbertc]

I like removing Xor and XorT in favor of Either (stdlib) and EitherT (a rename of XorT). Since Either will be right-biased starting in Scala 2.12, with libraries like Argonaut FS2 and Scodec using Either, and since we often recommend folks import cats.implicits._ anyways (so we can add methods we want via enrichment) it seems moving to Either would provide some conveniences for users. In my experience having used Scodec, one of the pain points is getting an Either and having to convert it myself. In general conversions back and forth are a pain.

I'm sure there will be some opposition so I'll wait for them to speak up :-) Otherwise if nobody complains I'll try to put a patchset together this weekend.

[mpilquist]

@adelbertc Any thoughts on 2.10/2.11 compatibility? E.g., would import cats.implicits._ patch right-biasness on to Either?

[adelbertc]

@mpilquist Yeah that's what I was thinking. Users will have to pay a penalty if they wish to stick with a la carte imports, I'm guessing via cats.syntax.either._ or something like that. Though that also opens the doors for Cats beginning to support syntax for stdlib types, something in the past we've decided not to do. But I do think the benefit of moving onto stdlib Either is something worth considering, I've always found it weird we use Option, List, etc but have our own Either.

It also makes for some funny explanations when I say "Cats sticks with stdlib types when possible... oh except for Either..." And when encouraging folks to use Either in lieu of Try or just throwing I constantly find myself saying "I would use Either... except Either isn't really good because it's unbiased... Cats has Xor... but now you have to bring in a whole dependency just to get Either." While that's more an issue of the Scala stdlib, it'd be nice if in the future I could say use Either, and bring in Cats to get even more goodies with it versus you could use Either now... and switch to cats.data.Xor in the future maybe?

Also if simple right-biased monadic Either is what people want, we already have the instance. Importing syntax then gets us what we're after:

scala> val e0: Either[String, Int] = Right(5)
e0: Either[String,Int] = Right(5)

scala> val e1: Either[String, Int] = Left("boo")
e1: Either[String,Int] = Left(boo)

scala> for {
     |   a <- e0
     |   b <- e1
     | } yield b
<console>:15: error: value flatMap is not a member of Either[String,Int]
         a <- e0
              ^
<console>:16: error: value map is not a member of Either[String,Int]
         b <- e1
              ^

scala> import cats.implicits._
import cats.implicits._

scala> for {
     |   a <- e0
     |   b <- e1
     | } yield b
res1: scala.util.Either[String,Int] = Left(boo)

[adelbertc]

Oo I also just realized you can do (possibly immoral) tricks like this:

import scala.util.{Either => SEither}

package object foo {
  implicit class Either[A, B](val either: SEither[A, B]) extends AnyVal {
    def map[C](f: B => C): SEither[A, C] = either match {
      case Left(a)  => Left(a)
      case Right(b) => Right(f(b))
    }
  }
}

// in REPL

scala> val e: Either[String, Int] = Right(5)
e: Either[String,Int] = Right(5)

scala> e.map(_ + 1)
<console>:13: error: value map is not a member of Either[String,Int]
       e.map(_ + 1)
         ^

scala> import foo.Either
import foo.Either

scala> e.map(_ + 1)
res1: scala.util.Either[String,Int] = Right(6)

[soc]

@mpilquist You could have a version-specific import, which would add the missing methods to Either on 2.10/2.11 and would be empty on 2.12.

[adelbertc]

So assuming nobody objects to this today I'll start work on this tomorrow. My plan:

1. Add any missing methods currently available on Xor to Either via an implicit class available under cats.syntax.either
2. Redo XorT to be centered around Either
3. Fix the compiler errors (yay types!)

[travisbrown]

I finally get to use the 👎 on GitHub! 😄

As I said on Gitter, I'm strongly opposed to removing Xor (or replacing it with Either in the Cats API), at least until we stop supporting 2.11, and probably after.

Relying on extension methods for something as basic as flatMap on a core type like this just isn't worth whatever interop benefits we'd get by using Either everywhere. It's either more noise or more imports and magic, more bytecode, more runtime overhead, less Java-friendly, etc.

[adelbertc]

@travisbrown Is there as big of a performance difference with an implicit value class?

[travisbrown]

@adelbertc It helps in the for-comprehension case, but then you're balancing a flatMap you get directly vs. the one you get from the Monad instance and syntax, you've got different sets of imports that do the same thing but work very differently, and in general it's just a whole big awful bag of half-broken Scala magic instead of nice and simple Xor.

[soc]

@travisbrown This sounds all very unspecific to me. Are there some specific issues that you can share?

[travisbrown]

@soc For the record, here's one concrete example of that kind of prioritization issue.

[djspiewak]

Strongly in favor. Data classes like Xor, State and (to a lesser extent) Kleisli are incredibly hard to work around, compatibility wise, when you're talking in terms of middleware frameworks. fs2 is already using Either, and it seems like http4s is going to standardize on Either for broadly the same reason. Even if cats keeps Xor, there's a very real chance that no one will use it in the end.

I feel the runtime overhead of implicits needed in the short term is very manageable. I don't disagree that the prioritization issue is real if done via imports. I think the better approach would be to add the implicit to the Xor companion object. The downside is you get the slower one by default then if you import monad implicits, but the upside is that a) you don't need an import at all, and b) you never get ambiguities.

Does anyone know if members of supertypes of imported objects are at a lower priority than members of the imported object itself? Somehow I doubt that would override import ordering though. (edit they aren't at a lower priority)

[travisbrown]

@djspiewak I don't understand what you mean by the Xor companion object here, or how you could make Either behave consistently across 2.11 and 2.12 without imports.

[djspiewak]

@travisbrown Oh derp. For some reason I thought we could put the implicit magic in Xor's companion and somehow have that resolve for Either. Blame it on travel fatigue. Imports are clearly required, but I feel that's a relatively small price to pay.

[alexandru]

In my projects I already preferred Either to Xor, even before finding out that Either will be right biased in 2.12. The reason is that Either is standard and in use much more than alternatives like Xor will ever be. And this is important for interoperability and learning curve. Don't get me wrong, the right bias is cool, but using a right projection on Either is a bearable nuisance. Plus I actually miss those projections when the left value is not just some error I want to ignore. So now that Either will be right biased, I'll probably never use Xor.

That said, consider that Scala 2.11 will be around for a really long time, because 2.12 is the version that breaks compatibility with Java 6.