Id instances cannot be removed from the scope

[djspiewak]

This is the best thing ever:

cats.Monad[cats.Id]

No imports. That compiles. Credit to @edmundnoble for finding the original issue here: djspiewak/shims#20

The problem here is that catsInstancesForId is defined in the cats package object. This is a problem because the cats package is a component of the cats.Id type, and the cats package object is its own companion, meaning that the cats package object part of the implicit scope (without any imports!) used when resolving any type in the cats package (or presumably, any subpackage). This would also be a problem if other implicits were defined in the cats package object, but the Id instances are the only ones.

As far as I can tell, this scoping issue is pretty innocuous (if a bit leaky) if you're only using cats. Unfortunately, the moment you have scalaz on the classpath (you don't even need imports!) and are using shims, you end up in a world of hurt. See the issue I linked for an example.

The solution here is to unfortunately break compatibility. Implicits should be banned from the cats package object, and the Id instances should be moved to something like cats.implicits.id.

[kailuowang]

Thanks for reporting this. Do you mind provide a bit more specifics on how this hurts people with scalaz in class path? I mean all data types defined in cats have instances defined in companion objects and thus in scope without imports. I understand Id is special but curious how it affects differently in this scenario. Thanks!

[johnynek]

Actually removing implicit annotation is Mima compatible. So, we could keep the vals/defs but remove implicit.

[djspiewak]

@johnynek Oh good call! Not source compatible, but binary.

@kailuowang It affects people in the scalaz namespace (as scalaz affects people in the cats namespace) as described in the linked shims ticket. It appears that the compiler considers both Id types to be equivalent by some notion of compatibility when viewed through the shims implicit mechanisms. This may be a bug in scalac, I’m not sure. But the net result is that scalaz and cats having this problem results in ambiguities for the other when shims is in scope, since shims makes instances for each equivalent to the other.

[kailuowang]

Thanks for detail @djspiewak

[armanbilge]

As far as I can tell, this scoping issue is pretty innocuous (if a bit leaky) if you're only using cats.

I'd say that's a safe assumption nowadays.