Paweł Marks, VirtusLab
Greetings from the Scala 3 team! We are glad to announce that Scala 3.0.2 is now officially out. As no critical bugs have been found in the previously released Scala 3.0.2-RC2, it has been promoted to 3.0.2 and is the current stable Scala version. Recently, we are more and more confident that we can release stable versions of the compiler frequently and regularly. So, we have decided that the blog posts should focus more on stable features available for all users in the latest release of scala. So here, as a refresher, you have a summary of the most significant changes introduced in 3.0.2.
What’s new in 3.0.2
Improved insertion of semicolons in logical conditions
Scala 3’s indentation based syntax is aimed at making your code more concise and readable. As it gets broader adoption, we consistently improve its specification to eliminate corner cases which might lead to ambiguities or counterintuitive behaviours.
Thanks to #12801 it is now allowed for a logical expression in an if
statement or expression to continue in the following line if it starts in the same line as the if
keyword, e.g.
if foo
(bar)
then //...
can now be used instead of
if foo(bar)
then //...
If your intention is to have a block of code evaluating into a single condition you should add a new line and indentation directly after if
, e.g.
if
val cond = foo(bar)
cond
then //...
so code like below would NOT be valid
if val cond = foo(bar)
cond
then //...
Towards better null safety in the type system
The compiler option -Yexplicit-nulls
modifies Scala’s standard type hierarchy to allow easier tracing of nullable values by performing strict checks directly on the level of the type system rather than just relying on conventions (e.g. this prevents you from writing code like val foo: Option[String] = Some(null)
, which would be otherwise valid Scala although very likely to cause a NullPointerException
at some further point).
After the recently introduced changes with this option enabled the Null
type becomes a subtype of Matchable
instead of inheriting directly from Any
, making the code below compile (this used to compile before only without strict nullability checking).
def foo(x: Matchable) = x match { case null => () }
Method search by type signature
You can now browse the documentation of Scala’s API not only by names of methods but also by their type in a Hoogle-like manner (but with Scala syntax) thanks to integration with Inkuire brought up by #12375.
To find methods with the desired signature simply write in scaladoc’s searchbar the type you would expect them to have after eta-expansion (as if they were functions rather than methods).
Typing escape hatch for structural types
Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn’t normally play well with method overloading because some types of reflective dispatch algorithms (inlcuding JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
class Sink[A] { def put(x: A): Unit = {} }
val a = Sink[String]()
val b: { def put(x: String): Unit } = a
This code won’t compile. This is because when Sink[String]
gets erased to Sink[Object]
(as it’s seen from JVM’s perspective) the method’s signature becomes put(x: Object): Unit
while for the structural type it remains unchanged as put(x: String): Unit
and they wouldn’t match in runtime therefore Sink[String]
cannot be treated as a subtype of { def put(x: String): Unit }
.
We might however try to write a better method dispatch algorithm ourselves instead of relying on the JVM’s default one to make this work. To assure the compiler that we know what we’re doing we’ll need to use the new Selectable.WithoutPreciseParameterTypes
marker trait. Currently it’s an experimental feature (introduced by #12268) so you’ll be able to use it only with a snapshot or nightly version of the compiler and you’ll need to annotate all subtypes of this trait with @experimental
.
import annotation.experimental
@experimental trait MultiMethodSelectable extends Selectable.WithoutPreciseParameterTypes:
// smartly choose the right method implementation to call
def applyDynamic(name: String, paramTypes: Class[_]*)(args: Any*): Any = ???
@experimental class Sink[A] extends MultiMethodSelectable:
def put(x: A): Unit = {}
val a = new Sink[String]
val b: MultiMethodSelectable { def put(x: String): Unit } = a
This snippet will compile as the compiler won’t perform the precise signature check for b
anymore.
Other changes
Beside that scala 3.0.2 introduced multiple small improvements, mainly in metaprogramming, and fixed handful of bugs. You can see the detailed changelog on GitHub.
What’s next
We have decided that it is the right time for the first minor version after the initial release of Scala 3. Together with stable version 3.0.2, we have released the first release candidate for Scala 3.1. You can already use 3.1.0-RC1 and test not only the new experimental features like safer exceptions but also Scastie embedded in Scaladoc pages, improvements in JVM bytecode generation, the possibility to configure the compiler warnings and lots of smaller improvements and fixes all across the board. You can find the full changelog for 3.1.0-RC1 on GitHub.
You can expect the stable release of Scala 3.1 in the middle of October.
Contributors
Thank you to all the contributors who made the release of 3.0.2 possible 🎉
According to git shortlog -sn --no-merges 3.0.1..3.0.2
these are:
94 Martin Odersky
60 Liu Fengyun
47 Kacper Korban
28 Filip Zybała
18 Andrzej Ratajczak
17 Guillaume Martres
15 Jamie Thompson
10 bjornregnell
9 tanishiking
8 Dylan Halperin
8 Anatolii Kmetiuk
8 Tom Grigg
7 Paweł Marks
5 Som Snytt
5 changvvb
5 Michał Pałka
5 Krzysztof Romanowski
4 Aleksander Boruch-Gruszecki
4 Sébastien Doeraene
4 Nicolas Stucki
3 Phil
3 Magnolia.K
2 xuwei-k
2 Ben Plommer
2 Florian Schmaus
2 Lukas Rytz
2 Maciej Gorywoda
2 Markus Sutter
2 Roman Kotelnikov
2 Stéphane Micheloud
2 noti0na1
2 vincenzobaz
1 Ondrej Lhotak
1 KazuyaMiayshita
1 odersky
1 Julian Mendez
1 Anton Sviridov
1 GavinRay97
1 EnzeXing
1 Tomas Mikula
1 Tomasz Godzik
1 Vaastav Arora
1 Vadim Chelyshov
1 Will Sargent
1 Zofia Bartyzel
1 Dale Wijnand
1 Bjorn Regnell
1 dmitrii.naumenko
1 Adrien Piquerez
1 Meriam Lachkar
1 Martin
1 Olivier Blanvillain
1 Lorenzo Gabriele
Library authors: Join our community build
Scala 3 now has a set of widely-used community libraries that are built against every nightly Scala 3 snapshot. Join our community build to make sure that our regression suite includes your library.