Announcing Dotty 0.14.0-RC1 with export, immutable arrays, creator applications and more
Hello! This is the 14th release of Dotty. Some of the most interesting changes in this release include the new export
, the dual of import
, feature, an immutable array type and the creator applications syntax.
This release serves as a technology preview that demonstrates new language features and the compiler supporting them.
Dotty is the project name for technologies that are being considered for inclusion in Scala 3. Scala has pioneered the fusion of object-oriented and functional programming in a typed setting. Scala 3 will be a big step towards realising the full potential of these ideas. Its main objectives are to
- become more opinionated by promoting programming idioms we found to work well,
- simplify where possible,
- eliminate inconsistencies and surprising behaviours,
- build on strong foundations to ensure the design hangs together well,
- consolidate language constructs to improve the language’s consistency, safety, ergonomics, and performance.
You can learn more about Dotty on our website.
This is our 14th scheduled release according to our 6-week release schedule.
What’s new in the 0.14.0-RC1 technology preview?
Export as a dual of Import
A new export
keyword is added to the language that defines aliases for selected members of an object. Consider the following example:
class BitMap
class InkJet
class Printer {
type PrinterType
def print(bits: BitMap): Unit = ???
def status: List[String] = ???
}
class Scanner {
def scan(): BitMap = ???
def status: List[String] = ???
}
class Copier {
private val printUnit = new Printer { type PrinterType = InkJet }
private val scanUnit = new Scanner
export scanUnit.scan
export printUnit.{status => _, _}
def status: List[String] = printUnit.status ++ scanUnit.status
}
When defined like this, the Copier
class defines aliases of the scanner
's scan
method and all the methods of printUnit
except the status
method. You can hence call them on the Copier
as follows:
val copier = new Copier
copier.print(copier.scan())
The motivation for this change is to promote composition over inheritance. In OOP languages it is easy to define inheritance but the above example would be tricky if you follow the composition route. One would need to implement proxy methods in the Copier
to delegate to those of the Scanner
and the Printer
.
With the export
feature, making the Copier
behave as the Printer
and the Scanner
became much more ergonomic. Also, note the fine-grained control over which methods are exposed in cases of the possible method collision, as shown with the status
method example.
For more information, please read more in the documentation.
An immutable array type
A new type, scala.IArray[T]
, is added, which is an immutable version of the Array
type. Its implementation deserves a special attention, as it uses the new Dotty features in an elegant way (the below is an abstract from the corresponding commit:
opaque type IArray[T] = Array[T]
object IArray {
implied arrayOps {
inline def (arr: IArray[T]) apply[T] (n: Int): T = (arr: Array[T]).apply(n)
inline def (arr: IArray[T]) length[T] : Int = (arr: Array[T]).length
}
def apply[T: ClassTag](xs: T*): IArray[T] = Array(xs: _*)
/*...*/
}
Essentially, the above defines a wrapper around the ordinary Array
which exposes only its apply
(to get an element by index) and length
methods:
opaque type IArray[T]
defines a type which is known to be anArray
, but this information is known only in its companion objectIArray
. To the rest of the world, this information is not available.- The
implied arrayOps
implied instance defines the extension methods that expose the operations available on theIArray
type. - The extension methods,
apply
andlength
, delegate to these of theArray
type. These methods are inlined which means the performance footprint is the same as that of the originalArray
methods. - Because the methods are
inline
and because theIArray
type isopaque
, we need the(arr: Array[T])
casts.IArray
is known to be equal toArray
only inside theIArray
object and the inlining will cause the extension methods' bodies to appear outside theIArray
object when these methods are called.
Creator Applications
This new language feature is a generalisation of the ability to construct case classes without the new
keyword:
class StringBuilder(s: String) {
def this() = this("")
}
StringBuilder("abc") // same as new StringBuilder("abc")
StringBuilder() // same as new StringBuilder()
The motivation for the feature is mainly ergonomic. To make it possible, a new interpretation was added to a function call f(a)
. Previously, the rules were as follows:
Given a function call f(args)
,
- if
f
is a method applicable toargs
, typecheckf(args)
unchanged, - otherwise, if
f
has anapply
method applicable toargs
as a member, continue withf.apply(args)
, - otherwise, if
f
is of the formp.m
and there is an implicit conversionc
applicable top
so thatc(p).m
is applicable toargs
, continue withc(p).m(args)
There's now a fourth rule following these rules:
- otherwise, if
f
is syntactically a stable identifier, andnew f
wheref
is interpreted as a type identifier is applicable toargs
, continue withnew f(args)
.
For more information, please see the documentation.
Other changes
Some of the other changes include:
infer
method renamed tothe
, the semantics of which is now the same as that of thethe
method of Shapeless. Namely, the implicits are resolved more precisely – see this gist for an example in Shapeless, and the Dotty documentation for more details.- The syntax of quoting and splicing was changed. Now the quoting is expressed via
'{ ... }
and'[...]
and splicing – via${...}
and$id
. Please see the documentation for more details on these features.
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.13.0-RC1..0.14.0-RC1
these are:
214 Martin Odersky
151 Nicolas Stucki
71 Liu Fengyun
53 Guillaume Martres
26 Olivier Blanvillain
10 Aleksander Boruch-Gruszecki
9 Aggelos Biboudis
6 Miles Sabin
4 Allan Renucci
4 Dale Wijnand
3 Anatolii Kmetiuk
2 Fengyun Liu
2 Alex Zolotko
1 gnp
1 tim-zh
1 Dmitry Petrashko
1 Dotty CI
1 Jasper Moeys
1 Jentsch
1 Jim Van Horn
1 Lionel Parreaux
1 Master-Killer
1 Olivier ROLAND
1 Robert Stoll
1 Seth Tisue
1 Tomasz Godzik
1 Victor
If you want to get your hands dirty and contribute to Dotty, now is a good time to get involved! Head to our Getting Started page for new contributors, and have a look at some of the good first issues. They make perfect entry points into hacking on the compiler.
We are looking forward to having you join the team of contributors.