Add Either#toEitherNel extension and friends

[kubukoz]

Also brings Ior#toIorNel.

I'm also pondering submitting an EitherTNel type alias in the cats.data package object, together with conversions from EitherT, but then we'd need to do the same for IorT I guess.

[kubukoz]

I imagine it's going to get tedious if we have all these helpers for NonEmptySet and NonEmptyChain...

[ceedubs]

To add to the permutations: should we be making these for NonEmptyChain now? That seems to be the direction that we are encouraging people to go with #2472. I'm guessing that supporting both would be most helpful (but starts to feel like potential bloat).

[kubukoz]

Maybe we could generalize with something like `.leftPure[NonEmptyChain]` for now

…

On Fri, Sep 7, 2018, 17:26 Cody Allen ***@***.***> wrote: To add to the permutations: should we be making these for NonEmptyChain now? That seems to be the direction that we are encouraging people to go with #2472 <#2472>. I'm guessing that supporting both would be most helpful (but starts to feel like potential bloat). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2npB_nAbdNAJTSyXCQi47R8T76ujyOks5uYpAqgaJpZM4WdbfE> .

[catostrophe]

Agree with @ceedubs - the whole codebase should be reviewed and each *Nel function should get its *Nec pair. I tried to switch to Nec in my project via "replace all" but couldn't due to lack of some functions.

[easel]

Seems like a reasonable addition. I agree it would be good to add the equivalent Nec methods, not sure it needs to block this one though.

[kubukoz]

Created #2539 to track NEC equivalents. I suggest we proceed with this one as it is :)

[ceedubs]

👍 LGTM

[kubukoz]

Can we merge? It'll unblock #2543 which will conflict with this

[kubukoz]

Thanks!