What is the primary technical challenge that Scala's implicit solves?

Question

While learning Scala, I found the concept of implicit difficult to rationalize. It allows one to pass values implicitly, without explicitly mentioning them.

What is its purpose for being and what is the problem that it seeks to solve?

Answer 1

At it's heart, implicit is a way of extending the behavior of values of a type in a way that's fully controllable on a local level in your program, and external to the original code that defines those values. It's one approach to solving the expression problem.

It lets you keep your core classes focused on their most fundamental structure and behavior, and factor out higher-level behaviors. It's used to achieve ad hoc polymorphism, where two formally unrelated data types can be seamlessly adapted to the same interface, so that they can be treated as instances of the same type.

For example, rather than your data model classes containing JSON serialization behavior, you can store that behavior elsewhere, and implicitly augment an object with the ability to serialize itself. This amounts to defining in an implicit instance, which specifies how your object can be viewed as "JSON serializable", rather than its original type, and it's done without editing real type of the object.

There are several forms of implicit, which are pretty thoroughly covered elsewhere. Use cases include enhance-my-library pattern, the typeclass pattern, implicit conversions, and dependency injection.

What's really interesting to me, in the context of this question, is how this differs from approaches in other languages.

Enhance-my-library and typeclasses

In many other languages, you accomplish this by monkey patching (typically where there is no type checking) or extension methods. These approaches have the downside of composing unpredictably and applying globally. In statically typed languages without a way of opening classes, you usually have to make explicit adapters. This has the downside of a lot of boilerplate. In both static and dynamic languages, you may also be able to use reflection, but usually with a lot of ceremony and complexity.

In Haskell, typeclasses exist as a first-class concept. They're global, though, so you don't get the local control over what typeclass is applied in a given situation. In Scala, you control what implicits are in scope locally, through the modules you import. And you can always opt out of implicit resolution entirely by passing parameters explicitly.

People advocate for global versus local resolution of typeclasses one way or the other, depending on who you ask.

Implicit conversions

A lot of other languages have no way to accomplish this. But it's become pretty frowned upon in Scala, so maybe this is for good reason.

Answer 2

There's a paper about type classes with older slides and discussion.

Being able implicitly to pass an object that encodes a type class simplifies the boilerplate.

Odersky just responded to a critique of implicits that

Scala would not be Scala if it did not have implicit parameters and classes.

That suggests they solve a challenge that is central to the design of the language. In other words, supporting type classes is not an ancillary concern.

Answer 3

Its a deep question really It is something that is very powerful and you can use them to write abstract code eg typeclasses etc i can recommend some tutorials that you may look into and then we can haved a chat maybe sometime :) It is all about providing sensible defaults in your code. Also the magic of invoking apparently non existent methods on objects which just seems to work! All that good stuff is done via implicits. But for all its power it may cause people to write some really bad code as well. Please do watch Nick Partridge's presentation here and i am sure if you code along with him you will understand why and how to approach implicits. Watch it here

Dick Walls excellent presentation with live coding Watch both parts.