It seems that the MonadCancel can have the mapK method or even this lift method. Did that discuss on discord or somewhere? I will be grateful for the link 🙏🏻
Anyway, I feel that this lift method is super-specific to have it within the client package. Maybe there is a more appropriate fp.utils package?

Yes, MonadCancel can have an imapK method :)

Yeah, bit of long discussion 😅
I propose my idea for this PR here:
https://discord.com/channels/632277896739946517/839254871646404638/954226420601716736
Then we discuss it here:
https://discord.com/channels/632277896739946517/839254871646404638/954238156767625266

I do agree this is weird one for Client 😆 @ChristopherDavenport is very suspicious about it though, which suggests we should keep it private-scoped to a small area. I can ask if CE will accept imapK addition.

Can anyone summarize the objection? Neither PR has a unit test: it would be great to see evidence that they satisfy the aim. Or if this approach doesn't work, a test that shows how it fails.

This one better fits the golden rule of software quality if it indeed works.

@ChristopherDavenport on Discord:

So I agree that will work, but I have been told and so practice that it is bad to override a typeclass like that.
As canonically a typeclass should have a single implementation for a type.

https://discord.com/channels/632277896739946517/839254871646404638/954238688676704328

He said he will throw up a unit test today.

Tests are push to my branch, feel free to steal them over here.

My implementation passes @ChristopherDavenport's tests.

On the theoretical question, is it any worse than:

• Parallel.applicativeError?
• Applicative.monoid?

I believe private[this] is more private than private. As mentioned before I'm not theory person and this version is much cleaner than mine.

private is also accessible from other instances of Client. private[this] is accessible only from the same instance of Client. Furthermore, private[this] is direct field access instead of through an accessor method. I think that change is conservative, and therefore good, until everyone is comfortable with it.

On theory, there's a nice Haskell discussion of Applicative.monoid by Gabriella Gonzalez.

I think there's nothing wrong with providing explicit derived instances like this, and let users promote them to implicit if they are judged to be the canonical instance for the type, or tuck them away as done here when they do the right thing.