What’s new in the 0.5.0-RC1 technology preview?

Reworked implicit search #3421

The treatment of ambiguity errors has changed. If an ambiguity is encountered in some recursive step of an implicit search, the ambiguity is propagated to the caller. Example: Say you have the following definitions:

class A
class B extends C
class C
implicit def a1: A
implicit def a2: A
implicit def b(implicit a: A): B
implicit def c: C

and the query implicitly[C].

This query would now be classified as ambiguous. This makes sense, after all there are two possible solutions, b(a1) and b(a2), neither of which is better than the other and both of which are better than the third solution, c. By contrast, Scala 2 would have rejected the search for A as ambiguous, and subsequently have classified the query b(implictly[A]) as a normal fail, which means that the alternative c would be chosen as solution!

Scala 2's somewhat puzzling behavior with respect to ambiguity has been exploited to implement the analogue of a "negated" search in implicit resolution, where a query Q1 fails if some other query Q2 succeeds and Q1 succeeds if Q2 fails. With the new cleaned up behavior these techniques no longer work. But there is now a new special type scala.implicits.Not which implements negation directly. For any query type Q: Not[Q] succeeds if and only if the implicit search for Q fails.

Dependent function types #3464

A dependent function type describes functions where the result type may depend on the function's parameter values. Example:

class Entry { type Key; key: Key }

def extractKey(e: Entry): e.Key = e.key          // a dependent method
val extractor: (e: Entry) => e.Key = extractKey  // a dependent function value

Scala already has dependent methods, i.e. methods where the result type refers to some of the parameters of the method. Method extractKey is an example. Its result type, e.key refers its parameter e (we also say, e.Key depends on e). But so far it was not possible to turn such methods into function values, so that they can be passed as parameters to other functions, or returned as results. Dependent methods could not be turned into functions simply because there was no type that could describe them.

In Dotty this is now possible. The type of the extractor value above is

(e: Entry) => e.Key

This type describes function values that take any argument x of type Entry and return a result of type x.Key.

TASTY frontend

TASTY is a new serialization format for typed syntax trees of Scala programs. When compiled by Dotty, a program classfile will include its TASTY representation in addition to its bytecode.

The TASTY frontend uses ASTs from the TASTY in classfiles as input instead of source files. There are currently two backends using the TASTY frontend:

• A Dotty class file decompiler that let you decompile code previously compiled to TASTY:

  dotc -decompile -classpath <classpath> <classname>
  

• A Dotty TASTY compiler that will recompile code previously compiled to TASTY:

  dotc -from-tasty -classpath <classpath> <classname>
  

  This is the first step toward linking and whole word optimisations, recompiling code to a different backends...

Generic java signatures #3234

Dotty now emits generic signatures for classes and methods. Those signatures are used by compilers, debuggers and to support runtime reflection. For example:

scala> class Foo[T, U]
// defined class Foo

scala> classOf[Foo[_, _]].getTypeParameters.map(_.getName).mkString(", ")
val res0: String = "T, U"

Trying out Dotty

Scastie

Scastie, the online Scala playground, supports Dotty. This is an easy way to try Dotty without installing anything.

sbt

Using sbt 0.13.13 or newer, do:

sbt new lampepfl/dotty.g8

This will setup a new sbt project with Dotty as compiler. For more details on using Dotty with sbt, see the example project.

IDE support

It is very easy to start using the Dotty IDE in any Dotty project by following the IDE sections of the getting-started page.

Standalone installation

Releases are available for download on the Releases section of the Dotty repository: https://github.com/lampepfl/dotty/releases

We also provide a homebrew package that can be installed by running:

brew install lampepfl/brew/dotty

In case you have already installed Dotty via brew, you should instead update it:

brew upgrade dotty

Let us know what you think!

If you have questions or any sort of feedback, feel free to send us a message on our Gitter channel. If you encounter a bug, please open an issue on GitHub.

Contributing

Thank you to all the contributors who made this release possible!

According to git shortlog -sn --no-merges 0.4.0-RC1..0.5.0-RC1 these are:

   112  Nicolas Stucki
   108  Martin Odersky
    33  Allan Renucci
    18  Guillaume Martres
    17  Martin Duhem
    13  liu fengyun
     9  Miron Aseev
     4  Matt D'Souza
     4  Raphael Bosshard
     2  k0ala
     2  Vitor Vieira
     2  Fengyun Liu
     2  Michal Gutowski
     2  Robert Soeldner
     2  Aurélien Richez
     1  rsoeldner
     1  Hermes Espínola González
     1  Jean Detoeuf
     1  Karol Chmist
     1  Olivier Blanvillain
     1  William Narmontas
     1  Yevgen Nerush
     1  gan74
     1  gosubpl

If you want to get your hands dirty and contribute to Dotty, now is a good time to get involved! You can have a look at our Getting Started page for new contributors, the Awesome Error Messages project or some of the simple Dotty issues. They make perfect entry-points into hacking on the compiler.

We are looking forward to having you join the team of contributors.

Library authors: Join our community build

Dotty now has a set of widely-used community libraries that are built against every nightly Dotty snapshot. Currently this includes ScalaPB, algebra, scalatest, scopt and squants. Join our community build to make sure that our regression suite includes your library.