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