4

Lets say I develop a new public data structure, lets call it FancyList. It has no external dependencies and everybody loves it.
This FancyList turns out to be a Functor, Monad, MonoidK, and Traverse.
What is the best way to provide cats instances for these type classes to my users? The way I see it I can put them:

On the same library

  • Con: Users that don't care about cats now depend on this library. Source code is also more confusing for them.
  • Pro: If I put the instances within the companion object of FancyList, implicit resolution will automatically find them, without the need for the user to import implicits explicitly (the same way no need to import cats.implicits._ for instances on NonEmptyList)

On a new library

  • Pro: No external dependencies. Big plus on simplicity.
  • Con: Users that do care about cats would 1) Have to import an extra dependency, and 2) Import the implicit evidences explicitly ( the same way you have to import cats.implicits._ for instances on structures on the standard library).

Also, what if next month users ask support for scalaz? Which of the approaches would be more appropriate?

In general, my questions are:

  • Is my pro/cons list accurate? Did I miss something?
  • What are the main arguments that I should consider?
  • What have other libraries in similar positions done? Any example you could give?
Dmytro Mitin
  • 48,194
  • 3
  • 28
  • 66
cmhteixeira
  • 877
  • 11
  • 22
  • 3
    Yes your understanding is more or less correct, except that nobody ever will ask for **scalaz** support. Which option to choose depends on what would you expect your userbase to be, if majority of them will be **cats** users go for option 1, otherwise option 2. – Luis Miguel Mejía Suárez Jun 18 '21 at 23:03
  • 2
    scalaz isn't dead. cats is newer, sure, but they both have sizeable user bases. From my experience, there's nothing wrong with either of them. But to answer the OP, yep, you're right on the money. I'd tend to favor option 2 unless your library already has a cats dependency. Scala devs are already pretty accustomed to importing `.implicits._` libraries from things; it's not a super unusual pattern – Silvio Mayolo Jun 18 '21 at 23:47
  • 1
    There is a similar situation with cats-effect typeclasses. Implementing effect types must choose between the two approaches you describe. For instance, Monix went for companion object instances and ZIO for instances in a separate library. – montrivo Aug 04 '21 at 19:43
  • https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-cats/ – Dmytro Mitin Oct 03 '21 at 19:17

0 Answers0