Proposal 0: ----------------
Do nothing
(+1) I'd be OK with the outcome being nothing changing, but in the case that it doesn't I have the following take
Proposal 1: ---------------- Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow
(-1) I don't find Control.Arrow to be a compelling abstraction and I don't want to drive more people to it only to use it simply for its (->) instances. Additionally I don't want think that learning more operators is the solution to applying functions to Either values.
Proposal 2: ---------------- Document Control.Arrow to exemplify the (->) instance usage.
(0) I'm OK with any changes that happen inside the Control.Arrow module
Proposal 3: ----------------
Implement mapLeft in Data.Either
3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow) 3b) ... as Control.Arrow.left 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft
(+1) for 3a. We don't need Arrow leaking out of its module. mapLeft is the actual operation in question. A user looking for operations on Either can switch to a more general operation later when it turns out he's writing a more general function.
Proposal 4: ----------------
Implement mapBoth in Data.Either
4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow) 4b) ... as Control.Arrow.(+++) 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth
(-1) the Both name invokes tuples for me
Proposal 5: ----------------
== Proposal 4, using the mapEither name instead.
(+1) same as 3a
Proposal 6: ----------------
Implement mapRight in Data.Either
6a) ... as (b -> c) -> Either a b -> Either a c 6b) ... as fmap
(+1) 6a. The code should be clear and gains nothing by exposing fmap's type or implementation and it should be an error for someone to use mapRight on a non-Either value
Proposal 7: ----------------
Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.
(-1) While it is true that fmap is mapRight for Either, that doesn't mean that the mapRight operation doesn't stand on its own.
Proposal 8: ----------------
Bring bifunctors to base.
(0) I'm fine with bifunctors moving into base, but I don't think it's relevant to this discussion. While it is the case that the Bifunctor abstraction also subsumes a map[Left,Right,Either], these operations continue to stand on there own. I'd advocate for using the general operations when the generality is called for and useful, not as a way to save on names. I similarly consider it inappropriate to remove (.) in favor of fmap