Paweł Marks, VirtusLab
We are thrilled to announce that after long months of work and careful testing, we have released Scala 3.3.0, the first release in the new 3.3.x LTS series.
What does “LTS” mean?
Scala 3.3.x is the first Long Term Support (LTS) release series. That means that it will be actively maintained for a period of at least three years. We have adopted a release model similar to the one that Java has successfully used for a long time.
In the following years, there will be new minor releases (3.4, 3.5, and so on) that can bring new backward-compatible features. We are calling them Scala Next; they are equivalent to Java’s feature releases. Bug fixes and usability improvements from those releases will be back-ported and released as 3.3.x patches. Apart from those forward and backward-compatible changes, LTS will be feature frozen.
The LTS model doesn’t change anything in our compatibility guarantees. Projects built with all future releases will be able to depend on any library compiled with Scala 3.3.x. This is just our standard guarantee that the newer compiler can always consume the output of the older version.
LTS might be a great choice for library authors who can now receive constant bug fixes and developer experience improvements without forcing the users of the library to update the compiler version in their project.
You can read more about our compatibility guarantees in the recent blog post.
What’s new in Scala 3.3.0
Linting
Scala 3.3.0 brings back linting to the Scala compiler. Right now, you can enable checking for unused symbols and discarded values. More linting options will come soon in the following Scala 3.3.x releases.
Checking for unused values
There is an entire family of compiler options added in 3.3.0 for checking and reporting different kinds of unused symbols:
-Wunused:imports- for unused imports-Wunused:privates- for unused local definitions-Wunused:locals- for unused local definitions-Wunused:explicits- for unused explicit parameters-Wunused:implicits- for unused implicit parameters (parameters inusingclauses)-Wunused:params- for all unused method parameters-Wunused:all- for enabling all of the above lints
Checking for discarded values
Discarding non-unit values is usually the symptom of subtle mistakes. The compiler can now warn you about all discarded values saving you from bugs resulting from those hard-to-spot mistakes.
In the following simplified example
def failure: Either[String, Nothing] = Left("something broke")
def failedComputation: Either[String, Unit] =
Right(()).map(_ => failure)
the programmer, by mistake, used the map method instead of flatMap. The code still compiles, but due to value discarding, behaves unexpectedly, returning Right(()) from the failedComputation method. If the -Wvalue-discard flag is enabled, the compiler will report the warning, saving the user from a potential bug.
More consistent braceless syntax
Braces around method parameters can now be replaced with a colon. This can lead to cleaner, shorter, and often more readable code in places like configuration DSLs or test case definitions.
def canFail(input: String): Try[List[String]] = Try:
someComputation(input).flatMap: res =>
val partial = moreComputation(res)
andEvenMore(partial)
class TestSuite extends munit.FunSuite:
test("the job doesn't fail"):
val job = canFail("some data")
assert(job.isSuccess)
For the record, the braceless syntax has been introduced in Scala 3.0.0. However, braces were still needed to pass function arguments. Martin Odersky proposed to address this point in the proposal SIP-44 - Fewer braces, which was accepted by the SIP Committee in August 2022. The final implementation was released as an experimental feature in Scala 3.2.0 in September. Finally, in October, the SIP Committee voted to promote it to a stable feature.
boundary and break
Two new methods were added to the standard library: boundary and break. They are safer and more expressive replacements for non-local returns, which were deprecated recently.
break allows for a type-safe early escape from anywhere inside the block delimited by boundary to its end, returning the passed value from the entire block.
import util.boundary, boundary.break
def sumOfRoots(numbers: List[Double]): Option[Double] = boundary:
val roots = numbers.map: n =>
println(s" * calculating square root for $n*")
if n >= 0 then Math.sqrt(n) else break(None)
Some(roots.sum)
When you run the above method, you will notice that it returns None when any of the input elements is negative. Moreover, thanks to boundary/break, you can see from the console output that it stops iterating after encountering the first negative element.
break can jump out of the boundary in the function deeper on the stack. To make it safe, only functions with a matching Label in their using clauses can break. This can be used to create isolated parts of an application with streamlined error handling. Library authors can abstract over break and Label, creating a nice API for error handling or dealing with uncertain data.
The new default implementation of lazy vals
Last but not least, we have changed the default implementation of lazy vals. The new implementation has better performance and is safer under parallel access. This may result in improvements in the performance of effect systems.
Should I update to Scala 3.3.0?
If you are maintaining a standalone Scala 3 project without external projects depending on it, feel free to switch to Scala 3.3.0 at any moment. You will enjoy all the improvements in the newest version of the compiler.
If you are a library author following semantic versioning, we advise you to update to Scala 3.3.0 in the next minor release of your project. Users of your library would also need to bump their compiler version to use the newest version of your library. If you have already published a minor version on 3.3.0 but learned about a critical vulnerability in your library, you should release a new patch release for the previous minor version of your library using the Scala version you had used before the bump (e.g. 3.2.2 or older). This patch can be consumed by all the users of previous versions of the library, no matter if they have already switched to 3.3.0 or not.
Known incompatibility: Stability of inline parameters
In Scala, only stable paths can be used as prefix in path-dependent types.
class Outer:
type Inner
val a = new Outer
val aInner: a.Inner = ??? // ok
var b = new Outer
// val bInner: b.Inner = ??? // error
def c = new Outer
// val cInner: c.Inner = ??? // error
def method(param: Outer): param.Inner = ??? // ok
There was a bug that resulted in the compiler assuming that all inline parameters are stable references. This could have led to unsound code being accepted by the compiler and potential runtime crashes.
inline def method(inline param: Outer): param.Inner // error in Scala 3.3.0
Such pieces of code are now rejected by the compiler. The migration for that change is simple, as it only requires removing the inline modifier from the parameter. If the path-dependent type was used, it is safe to say that the intended behavior was to inline the method without inlining the parameter.
Contributors
Thank you to all the contributors who made the release of 3.3.0 possible
According to git shortlog -sn --no-merges 3.2.2..3.3.0 these are:
226 Martin Odersky
106 Szymon Rodziewicz
81 Dale Wijnand
56 Nicolas Stucki
52 Paul Coral
48 Kamil Szewczyk
45 Paweł Marks
28 Florian3k
28 Yichen Xu
15 Guillaume Martres
10 Michał Pałka
9 Kacper Korban
8 Fengyun Liu
7 Chris Birchall
7 rochala
6 Sébastien Doeraene
6 jdudrak
5 Seth Tisue
5 Som Snytt
5 nizhikov
4 Filip Zybała
4 Jan Chyb
4 Michael Pollmeier
4 Natsu Kagami
3 Anatolii Kmetiuk
3 Jamie Thompson
2 Adrien Piquerez
2 Alex
2 Dmitrii Naumenko
2 Lukas Rytz
2 Michael Pilquist
2 Vasil Vasilev
2 adampauls
2 yoshinorin
1 Alexander Slesarenko
1 Chris Kipp
1 Guillaume Raffin
1 Jakub Kozłowski
1 Jan-Pieter van den Heuvel
1 Julien Richard-Foy
1 Kenji Yoshida
1 Matt Bovel
1 Mohammad Yousuf Minhaj Zia
1 Philippus
1 Szymon R
1 Tim Spence
1 s.bazarsadaev