- Implicit function types are a powerful way to abstract over contexts by defining types that inject implicit values into a scope. This can fundamentally change the code we write by removing boilerplate around passing implicit parameters and configurations.
- Implicit parameters are a core Scala feature that allow removing repetition through parameterization while enabling use cases like proving theorems, establishing context, and implementing type classes. Their scope may be expanded through implicit function types.
- Future Scala versions aim to tighten rules for implicit conversions while introducing features like lazy implicits, multiple implicit parameter lists, and coherence to improve the discoverability and reasoning around implicits.
3. Context is all around us
- the current configuration
- the current scope
- the meaning of “<” on this type
- the user on behalf of which the
operation is performed
- the security level in effect
…
4. - globals
rigid if immutable,
unsafe if mutable
- monkey patching
- dependency injection
at runtime (Spring, Guice)
or with macros (MacWire)
- cake pattern
close coupling + recursion
Traditional ways to express context
6. - no side effects
- type-safe
- fine-grained control
Functional is Good
7. - sea of parameters
- most of which hardly ever change
- repetitive, boring, prone to mistakes
But sometimes it’s too much of a
good thing …
8. If passing a lot of parameters gets tedious,
leave some of them implicit.
A more direct approach
9. • If there’s one feature that makes Scala “Scala”,
I would pick implicits.
• There’s hardly an API without them.
• They enable advanced and elegant
architectural designs.
• They are also misused way too often.
Implicits
10. • takes you through the most common uses of
implicits,
• gives recommendations of use patterns,
• goes through a set of proposed language
changes that will make implicits even more
powerful and safer to use.
This Talk
t
11. • If you do not give an argument to an implicit
parameter, one will be provided for you.
• Eligible are all implicit values that are visible at
the point of call.
• If there are more than one eligible candidate,
the most specific one is chosen.
• If there’s no unique most specific candidate, an
ambiguity error Is reported.
Ground Rules
12. • They are a cousin of implicit parameters.
• If the type A of an expression does not match
the expected type B …
Implicit Conversions
13. • They are a cousin of implicit parameters.
• If the type A of an expression does not match
the expected type B …
… the compiler tries to find an implicit
conversion method from A to B.
• Same rules as for implicit parameters apply.
Implicit Conversions
14. • Shorthand for defining a new class and an
implicit conversion into it.
implicit class C(x: T) { … }
expands to
class C(x: T) { … }
implicit def C(x: T) = new C(x)
Implicit Classes
15. • Implicits leverage what the compiler knows
about your code.
• They remove repetition and boilerplate.
• But taken too far, they can hurt readability.
When To Use Implicits?
16. Applicability:
Where are you allowed to elide implied information?
How do you find out this is happening?
Power:
What influence does the elided info have?
Can it change radically behavior or types?
Scope:
How much of the rest of the code do you need to know
to find out what is implied?
Is there always a clear place to look?
* Adapted from Rust’s Language Ergonomics Initiative
Reasoning Footprint of Implicitness*
20. Late Trait Implementation
Make existing classes implement new traits
without changing their code.
This was the original reason for implicits in Scala.
Discoverability: low to medium
Power: low to medium
Scope: large, but IDEs help
21. They also have some use cases, e.g.
• cached implicit classes
• context-dependent views
What about simple conversions?
22. • Conversions that go both ways
• Conversions that change semantics
E.g. collection.convert.WrapAs{Java,Scala}
Better: Use Converters
collection.convert.DecorateAs{Java,Scala}
Anti Patterns
28. Establish Context
Example: conference management system.
Reviewers should only see (directly or indirectly) the
scores of papers where they have no conflict with an
author.
33. What will change:
1. Tighten the rules for implicit conversions
2. Lazy implicits
3. Multiple implicit parameter lists
4. Coherence(?)
5. Implicit function types
34. 1. Tighten Rules for
Implicit Conversions
Question: What does this print?
Answer: java.lang.IndexOutOfBoundsException: 42
Hint: List[String] <: Function[Int, String]
35. In the future: Only implicit methods are eligible as
conversions.
A new class ImplicitConverter allows to abstract over
implicit conversions.
Converters are turned into conversions like this:
1. Tighten Rules for
Implicit Conversions
37. 2. Lazy Implicits
Problem: When synthesizing code for recursive data
structures, we get divergent implicit searches.
E.g.
will diverge if A expands recursively to Sum[A, B]
38. 2. Lazy Implicits
Solution: Delay the implicit search and tie the recursive
knot with a lazy val if a parameter is call-by-name:
This change, proposed by Miles Sabin, is a more robust
solution than the current “Lazy” type in shapeless.
40. 3. Multiple Implicit Parameter Lists
Problem: Implicit parameters are currently a bit irregular
compared to normal parameters:
• there can be only one implicit parameter section
• and it must come last.
This leads to some awkward workarounds (c.f. Aux
pattern).
Related problem: It’s sometimes confusing when a
parameter is implicit or explicit.
41. 3. Multiple Implicit Parameter Lists
Proposal:
• Allow multiple implicit parameter lists
• Implicit and explicit parameter lists can be mixed freely.
• Explicit application of an implicit parameter must be
marked with a new “magic” method, explicitly.
• Implementation status: Proposal. Main challenge is
migration from current Scala.
42. 4. Coherence
Difference between Scala’s implicits and Haskell’s type
classes: The latter are required to be coherent:
A type can implement a type class in one way only
(globally).
This is very restrictive, rules out most of the implicit use
cases we have seen.
But it also provides some benefits.
43. Coherence Rules Out Ambiguities
Say you have a capability system dealing with driver
licences:
If you can drive a truck and a cab, you should be able to
drive a car. But Scala would give you an ambiguity error.
44. Coherence Rules Out Ambiguities
Proposal:
• Allow type classes to declare themselves coherent.
• Have the compiler check that coherent traits have only
one implementation per type.
This is quite tricky. See github.com/lampepfl/dotty/issues/2047
• Drop all ambiguity checks for coherent implicits.
45. Parametricity
• It turns out that a necessary condition to ensure
coherence is to disallow operations like equals,
hashCode, isInstanceOf on coherent types.
• This restriction is useful in other contexts as well
because it gives us “theorems for free”.
• Proposal: Change Scala’s
top types to:
• AnyObj has all of current
Any’s methods. Any has only
the escape-hatch method
asInstanceOf.
47. 5. Implicit Function Types
Have another look at the conference management system:
In a large system, it gets tedious to declare all these
implicit Viewers parameters.
48. Can we do better?
Having to write
a couple of times does not look so bad.
But in the dotty compiler there are > 2600 occurrences of
the parameter
Would it not be nice to get rid of them?
51. Towards a solution
Let’s massage the definition of viewRankings a bit:
What is its type?
So far: Viewers => List[Paper]
From now on: implicit Viewers=> List[Paper]
or, desugared: ImplicitFunction1[Viewers, List[Paper]]
53. Two Rules for Typing
1. Implicit functions get implicit arguments just like implicit
methods. Given:
val f: implicit A => B
implicit val a: A
f expands to f(a).
2. Implicit functions get created on demand. If the
expected type of b is implicit A => B, then
b expands to implicit (_: A) => b
55. Efficiency
Implicit function result types can be optimized
Instead of creating a closure like this:
we can simply create a curried function like this:
This brings the cost of implicit functions down to simple
implicit parameters.
57. • The reader monad is a somewhat popular method to
pass context.
• Essentially, it wraps the implicit reading in a monad.
• One advantage: The reading is abstracted in a type.
• But I believe this is shooting sparrows with cannons.
• Monads are about sequencing, they have have nothing
to do with passing context.
The Reader Monad
58. • allow the same conciseness as the reader
monad,
• don’t force you into monadic style with explicit
sequencing,
• are fully composable,
• are more than 7x faster than the reader monad.
Implicit function types
59. Neat way to define structure-building DSLs, like this:
Natively supported in Groovy and in Kotlin via
“receiver functions”.
An encore: The Builder Pattern
61. • Any situation where an entity is implicitly
understood can be expressed with implicit
function types.
• We have seen:
“The current set of viewers”
“The structure to which current code should be added”
• Other possibilities:
“The current configuration”
“The currently running transaction”
“The capabilities needed to run this code”
"The effects this code has on the outside world”
…
Conjecture
63. • Implicit function types are a neat way to
abstract over contexts.
• It’s a very powerful feature, because it allows
one to inject implicit values in a scope simply
by defining a type.
• I expect it will fundamentally affect the kind of
code we will write in the future.
Summary (1)
64. • Implicit parameters are a fundamental and
powerful language construct.
• They are “just” parameterization, but remove
the boilerplate.
• One construct multifaceted use cases
• Abstractable using implicit function types.
• Implicit conversions are also very convenient,
but should be used with care.
Summary (2)
65. When Can I Expect This?
Scala 2.12
Scala 2.13
Scala 3.0
TASTY,
middle end?
stdlib
collections
dotty MVP
dotty 0.x releases
2016
backend, classpath handling
Scala 2.14
2017
2018
This is open source work, depends on community’s contributions.
Roadmap is tentative, no promises:
“MVP” = minimal
viable
prototype
66. Dotty:
Dmitry Petrashko Nicolas Stucki
Guillaume Martres Sebastien Douraene
Felix Mulder Ondrej Lhotak
Liu Fengyun Enno Runne
Close collaboration with scalac team @ Lightbend:
Adriaan Moors Seth Tisue
Jason Zaugg Stefan Zeiger
Lukas Rytz
Credits
OPEN GAMBIT
Multicore. Cloud computing. Containers. You’ll likely agree that the infrastructure for amazing scalability is in place, it’s been well funded. It’s the underpinning that’s required for enterprises to movie en masse to the cloud. But what are they moving?
Applications.
Applications that run their business, engage their customers, allow them to innovate and enter new markets.
Without applications, this infinitely scalable infrastructure is nothing.
OPEN GAMBIT
Multicore. Cloud computing. Containers. You’ll likely agree that the infrastructure for amazing scalability is in place, it’s been well funded. It’s the underpinning that’s required for enterprises to movie en masse to the cloud. But what are they moving?
Applications.
Applications that run their business, engage their customers, allow them to innovate and enter new markets.
Without applications, this infinitely scalable infrastructure is nothing.
