When does it make sense to use implicit parameters in Scala, and what may be alternative scala idioms to consider?

Question

Having used a Scala library that liberally exposes the reliance on implicits to the caller, I had experienced friction around this mechanism, as Scala makes it quite hard at times to debug implicit arguments, and because there's quite a bunch of places Scala would fill in values for implicit arguments from. (I could almost relate to it as "implicits hell" at one time).

At one time in my coding, Scala "complained" an implicit value could not be matched whereas in fact there was a "collision" of implicit values each coming from a different import.

Regardless of that perceived brittleness, it may at times feel borderline to an abuse of the context design pattern.

Why does it make sense to have implicit parameters in Scala? In what scenarios would you use them and how would you avoid trouble?

As I'm not sure the experimentation-curve and potential for other team members getting totally confused are worth it, could you possibly suggest other scala idioms for sharing context between a multitude of Scala functions?

This questions is not for a specific implementation at hand, hopefully it's still a good fit for this site.

Answer 1

Generally, using a common type as an implicit parameter is a bad idea.

def badIdea(n: Int)(implicit s: String) = s * n

It doesn't take much to imagine why: you'll get conflicting implicits for the same thing if anyone else adopts this policy. Better to avoid it.

But who really wants to manually stuff in a scala.concurrent.ExecutionContext manually every time it's needed (which is practically everywhere)?

So the key is: when you have something with a specialized type, especially if it's bookkeeping that might need to be overridden manually but mostly should just do the right thing, then use implicit parameters. (This usually covers type classes as well.)

Then what do you do if you really need a string? Well, wrap it (at least formally--here it's a value class so in some contexts it will just pass the string around):

class MyWrappedString(val underlying: String) extends AnyVal {}
implicit val myString = new MyWrappedString("bird")
def decentIdea(n: Int)(implicit mws: MyWrappedString) = mws.underlying * n

scala> decentIdea(2)  // In the bush?
res14: String = birdbird

Or if you think some additional logic is helpful, write a wrapper that takes an extra type parameter:

class ImplicitWithValue[K,V](val value: V) {
  // Any extra generic logic goes here
}
object ImplicitWithValue {
  class ValuePart[K] {
    def apply[V](v: V) = new ImplicitWithValue[K,V](v)
  }
  private val genericValuePart = new ValuePart[Any]
  private def typedValuePart[K] = genericValuePart.asInstanceOf[ValuePart[K]]
  def apply[K] = typedValuePart[K]
}

Then you can

trait Marker1
implicit val implicit1 = ImplicitWithValue[Marker1]("fish")

def goodIdea(n: Int)(implicit ms: ImplicitWithValue[Marker1, String]) = ms.value * n

scala> goodIdea(3)
res17: String = fishfishfish