Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MonadError syntax for OptionT uses incorrect instance #2611

Closed
wedens opened this issue Nov 14, 2018 · 4 comments
Closed

MonadError syntax for OptionT uses incorrect instance #2611

wedens opened this issue Nov 14, 2018 · 4 comments
Labels
Milestone

Comments

@wedens
Copy link
Contributor

wedens commented Nov 14, 2018

This PR introduced the problem: #2299

MonadError[OptionT[F, ?], Unit] is given higher priority than MonadError[F, E] => MonadError[OptionT[F, ?], E].

And, of course, syntax for MonadError always resolves the first instance making it useless for any E other than Unit.

@SystemFw
Copy link
Contributor

👍 to changing it back, http4s is affected, since you can't call handleErrorWith on HttpApp anymore (it's Kleisli of OptionT), basically for the purpose of using MonadError of Unit, which is close to a toy instance.

cc @rossabaker @ChristopherDavenport

@kailuowang
Copy link
Contributor

kailuowang commented Nov 14, 2018

+1 to fixing this.
We have two options:
1, We can simply make the Unit instance explicit
2. We can switch the two and use this trick to bump the priority of MonadError[F, E] => MonadError[OptionT[F, ?], E], (otherwise they probably will be of the same priority and causing ambiguity issue.) We also need to add 2 Mima exceptions (such changes were proven to be fine) and ideally one test to https://github.com/typelevel/cats/blob/master/binCompatTest/src/main/scala/catsBC/MimaExceptions.scala to make sure it works fine.

Possibly we can merge this fix to 1.5.x branch and be in time for the 1.5.x release

@kailuowang kailuowang added this to the 1.5 milestone Nov 14, 2018
@kailuowang kailuowang added the bug label Nov 14, 2018
@ChristopherDavenport
Copy link
Member

Definitely, 👍 to this being fixed.

@barambani
Copy link
Contributor

I'm having a look if that's all right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants