To my understanding, there was an historical reason for specifying two kinds of Or:
an inclusive one and an exclusive one (Either was not right biased).
Since Xor has been renamed to Either, both in stlib and in cats, I'm suggesting that Ior could be renamed as Or.
Benefits:
Ior thing?Issues :
I don't see it as a priority issue, but it could be added to the next major release.
It is appealing to imagine perfecting cats. Yet, I don’t like thinking of releases as a chance to break a bunch of stuff. Each break decreases the chance each user can easily adopt the new version.
We want as many users as possible to contribute and help find bugs. Breaks work against that goal.
I agree with @johnynek. Also note that the name Or is taken by org.scalactic.Or.
I am aware that breaking compatibility is a dire move, the question is
do you think the benefits of renaming
IortoOrare worth the cons?
Arguably, the ideal moment to rename that could have been while renaming Xor.
But -oh well- we can't go back in time to propose that 😸
Also note that the name Or is taken by org.scalactic.Or.
Ouch, org.scalactic.Or is even left biased 😓
By the way, one of my favorite features of scala is aliasing imports:
import cats.data.{Ior => Or}
if you like. One extra line of code... I still think the "inclusive" or is useful to understand what is going on here.
fwiw, I use a small DSL around Cats' Ior in this spirit here:
import cats.data.Ior
/** Syntactic sugars around [[cats.data.Ior]]s */
trait or {
type Or[+A, +B] = Ior[A, B]
…
}
object or extends or
as usual, you can import hammerlab.or._ directly, or mix or in to a package object to have it in scope in a whole package
I'd forgotten that I'd done this until I read this thread 😆 I don't think I use it super often, but just wanted to mention
I agree with @johnynek and @mpilquist that any potential benefits of this are outweighed by the headache that it would cause by breaking compatibility. And I do think that it does make the difference between this data structure and Either a bit clearer/more explicit.
Thanks for opening this and for working toward a better Cats @Bhudjo.
It sounds like so far there are several maintainers who are against this for compatibility reasons. I say that if there isn't much support for this vocalized in the next 2 weeks we go ahead and close it out.
Thanks for your kind comment @ceedubs.
I'm happy to have raised my point here, I also do understand yours.
Feel free to close this down whenever is appropriate.
Most helpful comment
By the way, one of my favorite features of scala is aliasing imports:
if you like. One extra line of code... I still think the "inclusive" or is useful to understand what is going on here.