You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update: now that we've switched to the Scalafix-powered version of Simulacrum (see #3424), we can easily deprecate these definitions, and I personally think we should do this in Cats 2.2.0. If anyone has objections please raise them here.
Cats currently has three ways of importing syntax methods for particular type classes. You can use the subpackage in syntax (this is the standard approach to à la carte imports):
While this last is at least different from the standard cats.syntax.abc._ approach, and maybe potentially useful, I've never actually seen anyone use it, or recommend it, and it has a serious downside—if you import ops._ from multiple type class companions, you lose the syntax methods for the intersection of their ancestors:
scala>importcats.instances.all._, cats.Traverse.ops._, cats.Alternative.ops._importcats.instances.all._importcats.Traverse.ops._importcats.Alternative.ops._
scala>List(1) <+>List(2) <+>List(3)
res0:List[Int] =List(1, 2, 3)
scala>List(Some(1), None, Some(2)).sequence
res1:Option[List[Int]] =None
scala>List(1, 2, 3).fmap(_ +1)
^
error: typemismatch;
found : List[Int]
required: ?{deffmap:?}
Note that implicit conversions are not applicable because they are ambiguous:
both method toAllTraverseOps in objectops of type [F[_], C](target: F[C])(implicittc: cats.Traverse[F])cats.Traverse.AllOps[F,C]{typeTypeClassType= cats.Traverse[F]}
and method toAllAlternativeOps in objectops of type [F[_], C](target: F[C])(implicittc: cats.Alternative[F])cats.Alternative.AllOps[F,C]{typeTypeClassType= cats.Alternative[F]}
are possible conversion functions from List[Int] to ?{deffmap:?}
Or even worse:
scala>List(1, 2, 3).as(0)
^
error: value as is not a member of List[Int]
did you mean last, map, or max?
…which is probably why nobody uses or recommends these.
So nonInheritedOps is redundant, and ops makes it really easy to shoot yourself in the foot. I think we should get rid of both of them in Cats 3, and deprecate them now.
These objects are generated by Simulacrum, and I'm not entirely sure it's possible to output deprecated methods using Scala 2's macro annotations (?), but if we move to the Scalafix approach this would be pretty easy.
The text was updated successfully, but these errors were encountered:
👍 Let's deprecate. The ops import is from the original Simulacrum encoding and the nonInheritedOps was to avoid the loss of syntax from common ancestors when importing multiple. They both predate mixing all syntax enrichments in to a single object (or rather, I was experimenting with an encoding that wouldn't require a Scalaz._ import).
Update: now that we've switched to the Scalafix-powered version of Simulacrum (see #3424), we can easily deprecate these definitions, and I personally think we should do this in Cats 2.2.0. If anyone has objections please raise them here.
Cats currently has three ways of importing syntax methods for particular type classes. You can use the subpackage in
syntax
(this is the standard approach to à la carte imports):You could also use the
nonInheritedOps
object in the type class companion, which does exactly the same thing:Or you can use the
ops
object in the companion of any descendant type class:While this last is at least different from the standard
cats.syntax.abc._
approach, and maybe potentially useful, I've never actually seen anyone use it, or recommend it, and it has a serious downside—if you importops._
from multiple type class companions, you lose the syntax methods for the intersection of their ancestors:Or even worse:
…which is probably why nobody uses or recommends these.
So
nonInheritedOps
is redundant, andops
makes it really easy to shoot yourself in the foot. I think we should get rid of both of them in Cats 3, and deprecate them now.These objects are generated by Simulacrum, and I'm not entirely sure it's possible to output deprecated methods using Scala 2's macro annotations (?), but if we move to the Scalafix approach this would be pretty easy.
The text was updated successfully, but these errors were encountered: