How Do Implicits Work in Scala?

Programmers strive to write simple and understandable code. The less code is written, the less likely it is that there is an error in it. Scala offers the ability to write even more concise code and rely on the help of the compiler. This is achieved through implicit conversions and implicit parameters. However, everything that is implicit, usually brings only misunderstanding. Let’s see what lies behind the magic of implicits in Scala.

Implicit conversions

Let’s start from implicit conversions. The purpose of their usage can be understood from the name - the transformation of data of one type into another (string into date, array into Option, soft into warm). If there is an implicit function A => B in the scope, the compiler can perform such a conversion:

Let’s see how scalac understands this code (here and throughout -Xprint:typer key is used for the compiler):

Indeed, the compiler adds another method to the chain of calls, so that the type of the passed parameter in the call method matches the required one.

Such way of using Scala’s implicit conversion is the most non-obvious. Only IDE and hours spent on debugging will let you find out why the call method works with the parameter of the wrong type. Do not abuse this kind of implicit conversions.

Extension methods

More predictable conversions are extension methods. They come to the rescue if we want to add a new method to the class, when we don't have access to its source code. The required functionality is added via a new implicit class:

Or, by using an implicit function that creates an anonymous class with the necessary methods:

Under the hood, the following happens (with an anonymous class function as an example):

As can be seen, before calling the “non-existent” method, a new object is created and this method is called on it. The presence of a specific method (albeit, at first glance, it is unclear where it came from) makes the code more readable and maintainable.

Implicit parameters

Another way for using the implicit magic of Scala is implicit parameters. The compiler can pass parameters to the function marked with the implicit keyword. Parameters can be either variables or functions:

The algorithm of actions is the same: the compiler finds in the scope the implicit with the needed type and passes it instead of us to the function:

Thus, we simplify the mandatory part of the signature function, and the ability to deal with the implicit is handed over to the compiler.

Type classes

By connecting the extension methods and implicit parameters together, you get a suitable tool for working with type classes. The typeclass is a characteristic that defines what the class can do, what operations can be performed with this class. The most obvious example from the standard library is the Ordering trait. It tells that objects of this type can be ordered. Let's create our own typeclass and convenient API using implicits:

Equal can be used directly (apply method):

and through the extension method that adds a method for comparison to any class (if there are corresponding implicits):

Since we have already gone over the approaches used in the last two examples, there are no surprises for us in the compiler’s actions:

Instead of conclusion, here are some truths from Captain Obvious:

  • no magic of implicits in Scala exists;
  • to avoid dealing with questions about where this or that implicit has come from, adhere to agreements on their placement and usage in your project.

The source code for the examples is available on Github.

Originally published at

We build software and we do it right | Custom web and mobile development |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store