-
Notifications
You must be signed in to change notification settings - Fork 15
Monad[Id] is ambiguous #20
Comments
Interesting. Shims isn't providing the instance itself, but it's hard to say for sure. |
Interesting that |
It's an aliasing issue. |
It appears that some witchcraft is summoning |
I figured it out. Both scalaz and cats scalaz.Monad[scalaz.Id.Id]
cats.Monad[cats.Id] Both those lines compile with no imports. So this is why things are ambiguous: both monads are in scope, and shims makes them equivalent. But, "how?!" you ask. Good question, intrepid reader! This gist shows a condensed example of the phenomenon in play here: https://gist.github.com/8680f463d4e2e4a8aa8a9e0bb7999ce0 The implicit scope for resolving a given type includes all companions of components of the type. As it turns out, one of the components of a type is the package itself, and the package object is considered part of the package scope. As you may recall from Shapeless's I would consider this to be a pretty significant design flaw in both frameworks, but in fairness, this is a really really obscure corner of implicit scoping. In the meantime, I'm not really sure if there's anything shims can do here. In theory, I'd really like shims implicits to be "magically lowest" priority in that they are only selected when no other implicits are applicable, but I don't have a handy trick for achieving that. |
To reproduce:
Result:
First encountered on shims 1.1, upgraded to shims 1.2.1 where the problem persisted.
Scalaz version 7.2.17, no cats imports.
EDIT: Worked around by shadowing
idInstance
in the scope where it's used. Perhaps shims is providing the instance itself somehow?The text was updated successfully, but these errors were encountered: