feat: +EitherT.liftRedeemK

[GreyPlane]

I found it is very handy for example lift from Future to EitherT but want to get rid of Throwable, just like attempt and redeem

[rossabaker]

Thanks!

Bikeshedding: the name "redeem" bothers me a bit, because the traditional redeem takes two functions. This is closer to adaptError, but that doesn't can't the type of the error like this does. It's also similar to leftMap, but then it loses its connection to error handling. So my ideas aren't quite right either.

I think I like it, but I wonder if anyone else has a better idea for a name.

[TheRealEugen]

I found it is very handy for example lift from Future to EitherT but want to get rid of Throwable, just like attempt and redeem

[TheRealEugen]

Details

[GreyPlane]

Thanks!

Bikeshedding: the name "redeem" bothers me a bit, because the traditional redeem takes two functions. This is closer to adaptError, but that doesn't can't the type of the error like this does. It's also similar to leftMap, but then it loses its connection to error handling. So my ideas aren't quite right either.

I think I like it, but I wonder if anyone else has a better idea for a name.

Ye, I also try to add that extra function that maps A => B, but that's still kind of different from original redeem since it only has one result type. though maybe it is still worth it since it will be more similar to the original one and keep the naming consistent.

[satorg]

Maybe liftRedeemErrorK? It is more verbose, but since it deals with errors only, the name could be more sounding.

[danicheg]

Sorry for bringing yet another variant for naming, but I like Ross's idea of proceeding with some form of adaptError 🤷🏻

[GreyPlane]

Sorry for bringing yet another variant for naming, but I like Ross's idea of proceeding with some form of adaptError 🤷🏻

I think i'd prefer liftAdaptErrorK, the difference between them looks intuitive to reason about since you're adapting Error into Either rather than abstract F.