What are the best practices for using implicits in Scala to avoid ambiguity and complexity? — Scala Interview Question #61

Implicits in Scala are a powerful feature that allows for more concise and expressive code. They can be used for various purposes like type conversions, implicit parameters, and context bounds. However, when used without care, implicits can also lead to ambiguity and complexity that might be hard to debug and maintain. To make the most of implicits while minimizing these issues, you can follow these best practices:

1. **Use implicit sparingly**: Do not overuse implicits, only apply them when it genuinely simplifies the code and enhances readability. If using an implicit makes the code more complex, it is best to avoid it.

2. **Don’t expose implicits globally**: Import implicits explicitly in the scope where they are needed, rather than making them globally available. Limiting the scope of implicits helps avoid unintended interactions and makes the code easier to reason about.

// Instead of importing globally,
// import scala.concurrent.ExecutionContext.Implicits.global

// Import specific implicit instances in the necessary scope.
{
  import scala.concurrent.ExecutionContext.Implicits.global

  // Use the execution context here.
}

3. **Explicit naming and well-documented**: Give your implicit values and conversions meaningful names that describe their intent. This makes it easier for other developers to understand the purpose of the implicit. Additionally, document how and why the implicit is used in the particular context.

// Bad example
implicit val ec: ExecutionContext = ... // No meaning

// Good example
implicit val blockingIOBoundExecutionContext: ExecutionContext = ...
// Document its usage and when to use it

4. **Define implicits close to the relevant type**: Place implicits close to the type they operate on, ideally, in the companion object of the type. This makes it easier to locate the implicits and prevents unintended conflicts.

case class CustomType(value: String)

object CustomType {
  // Define the implicit here
  implicit val customTypeOrdering: Ordering[CustomType] = ...
}

5. **Use Implicit classes for extension methods**: When extending an existing class using the "pimp my library" pattern, use implicit classes rather than implicit conversions. Implicit classes are more concise and only require a single implicit mechanism.

// Instead of using implicit def, use an implicit class for extension methods
implicit class StringOps(s: String) {
  def reverseAndToUpper: String = s.reverse.toUpperCase
}

val reversed = "scala".reverseAndToUpper // => "ALACS"

6. **Prefer type classes using context bounds**: Instead of using implicit parameters, prefer context bounds when working with type classes. The syntax is much cleaner and easier to understand.

// Instead of using an implicit parameter,
// def process[T](a: T, b: T)(implicit ord: Ordering[T]): List[T] = ...

// Prefer using a context bound
def process[T: Ordering](a: T, b: T): List[T] = {
  val ord = implicitly[Ordering[T]]
  // ...
}

7. **Use auxiliary modules for complex resolutions**: When you have complex implicit resolutions or implicit instances that depend on other instances, it is a good practice to use auxiliary objects or the so-called "Summoner Pattern" to wrap the instances and make the resolution process easier to reason about.

trait Mapper[A, B] {
  def map(a: A): B
}

object Mapper {
  // Provide summoning method
  def apply[A, B](implicit mapper: Mapper[A, B]): Mapper[A, B] = mapper
}

// Usage
def convert[A, B](a: A)(implicit mapper: Mapper[A, B]): B = {
  // Resolve Mapper[A,B] using the summoning method
  val mapperInstance = Mapper[A, B]
  mapperInstance.map(a)
}

By following these best practices, you can use implicits effectively while minimizing the associated risks of ambiguity and complexity. Remember, the key is to balance the expressive power of implicits with code maintainability and readability.