Scala 3.5.0 released!

We are happy to announce that after long and hard work by the entire compiler team, and after seven release candidates, the first version of the Scala 3.5 line is officially out!

New default runner - Scala CLI

Scala CLI is a popular tool among Scala devs. It allows lightning-fast running, testing, and prototyping of Scala scripts and single-module projects. In 3.5.0, it becomes part of the default Scala distribution. If you install Scala through popular package managers, such as Brew or SDKMAN!, the installed scala command allows you to compile, run, test, and even publish your code on Maven Central. It has out-of-the-box support for using directives, toolkits, compilation to JavaScript and native binaries, and other goodies formerly available only if you installed a separate tool.

Short example

Given the following file named biggerThan.scala

//> using dep com.lihaoyi::os-lib:0.10.3

@main def run(path: String, size: Int) =
  os.list(os.Path(path, os.pwd))
    .filter: p =>
      os.size(p) > size * 1024
    .foreach(println)

We can run scala biggerThan.scala -- ../my-directory 10. This will download os-lib and its transitive dependencies, compile the source code, and finally run the compiled program, printing all files in ../my-directory bigger than 10 kB. Subsequent invocations of the command will use cached bytecode, or if the source code changed, trigger incremental compilation.

As os-lib is a part of the default Scala Toolkit, we can replace //> using dep com.lihaoyi::os-lib:0.10.3 with //> using toolkit default. Furthermore, we can add #!/usr/bin/env -S scala shebang at the top of the file. Then, after setting the permissions (chmod +x biggerThan.scala), we can treat biggerThan.scala like any executable script. Invoking ./biggerThan.scala ../my-directory 10 will incrementally compile the file and then run it.

To learn the full scope of the new capabilities, read about Scala CLI commands and using-directives or glance at the cookbook.

Merging Scala CLI into the distribution doesn’t change the behavior of popular build tools that work with Scala, such as sbt, Mill, Maven, and Gradle. It does, however, allow for maintaining and publishing single-module multiplatform libraries without any build tool.

Note: Installation of a new Scala runner using Coursier requires it to be updated or reinstalled to Coursier 2.1.10 or above. Earlier versions did not support installing native packages, defaulted to the old runner JAR.

What’s new in 3.5.0?

Best effort compilation

When using Metals, the IDE functions work great on code that compiles. However, once the user starts changing the code, the support drops in quality. This gets worse with a larger number of compilation errors and subsequent modifications. In 3.5.0, we have fixed this problem. We introduced a new mode of compilation called Best Effort Compilation. When enabled, the compiler will output BETASTy files for not-currently-compiling code. It can be used by tooling to provide autocompletion and other IDE features.

To enable the use of BETASTy files in Metals, start the language server with -Dmetals.enable-best-effort=true or put that into metals.serverProperties setting in VS Code. We plan to enable this feature by default soon after gathering feedback from users.

Support for pipelined builds

Scala 3.5.0 supports pipelined compilation. It can be enabled by setting ThisBuild/usePipelining := true in sbt build definition. This can result in significant speedups in compilation time for multi-module projects.

You can learn more about how the pipelined compilation works and what benefits you can expect from the talk by Jamie Thompson.

var in refinements

Until now, only types, vals, and defs were allowed in type refinements. In 3.5.0, vars can also be declared.

type A = { var number: Int }

is now legal and equivalent to

type A = { def number: Int, def number_=($number: Int): Unit }

This change can simplify libraries based on metaprogramming using type refinements.

Support for binary integer literals

Integer literals can now start with 0b or 0B. They will be interpreted as numbers in base 2.

assert(0B1 == 1)
assert(0B10 == 2)
assert(0B_1000_0010 == 130)
assert(0B_1000_0010 == 0x82)

Experimental: named tuples

Scala 3.5 introduces experimental support for named tuples. The feature, hidden behind the language.experimental.namedTuples import, allows you to give meaningful names to tuple elements and use those names during constructing, destructuring, and pattern matching.

import scala.language.experimental.namedTuples

type Point = (x: Int, y: Int)
val point: Point = (x = 1, y = 2)
val is_it_point = (x = 5, y = 3)
val it_is: Point = is_it_point

println(point.x) // prints 1

point match
  case (x = real, y = 0) => println(s"Real number: $real")
  case _ => println("Point doesn't represent a real number")

This is an implementation of SIP-58.

Experimental: new givens and context bounds syntax

Another experimental feature introduced in Scala 3.5 is the new syntax for type classes. Some of these improvements are: Self type member instead of the type parameter, auxiliary type alias is or named context bounds, just to name a few. The full list of proposed improvements and their examples can be found under Modularity Improvements and Better Support for Type Classes. To test the new syntax you would be required to use both the source version future and the additional language import experimental.modularity.

//> using options -source:future -language:experimental.modularity

trait Ord:
  type Self
  extension (x: Self)
    def compareTo(y: Self): Int
    def < (y: Self): Boolean = compareTo(y) < 0
    def > (y: Self): Boolean = compareTo(y) > 0

given intOrd: (Int is Ord) with
  extension (x: Int) def compareTo(y: Int) = if x < y then -1 else if x > y then +1 else 0

def descending[T: Ord as asc]: T is Ord = new:
  extension (x: T) def compareTo(y: T) = asc.compareTo(y)(x)

def maximum[T](xs: List[T])(using T is Ord): T =
  xs.reduceLeft((x, y) => if (x < y) y else x)

val xs = List(1, 2, 3)
val _ = maximum(xs)
val _ = maximum(xs)(using descending)
val _ = maximum(xs)(using descending(using intOrd))

This is an implementation of SIP-64.

Work on a better scheme for given prioritization

Givens in Scala 3 have a peculiar problem with prioritization. The compiler tries to always select the instance with the most specific subtype of the requested type. This can lead to confusing situations, when user faces ambiguity errors in code that should intuitively work. Changing the scheme of given prioritization to always select the instance with the most general subtype that satisfies the context bound, would resolve such cases. We have conducted experiments that showed that the proposed scheme will result in a more intuitive and predictable given resolution. The negative impact on the existing projects is very small. We have tested 1500 open-source libraries, and new rules are causing problems for less than a dozen of them. We have already submitted PRs with changes that will make them work the same way under both the current and proposed rules.

For the detailed motivation of changes with examples of code that will be easier to write and understand, see our recent blogpost - Upcoming Changes to Givens in Scala 3.7.

Our current plan is to introduce the new scheme in Scala 3.7. Starting from Scala 3.6, code whose behavior can differ between new and old rules (ambiguity on new, passing on old, or vice versa) will emit warnings, but the old rules will still be applied. 3.5 gives you a chance to detect if those changes affect your codebase. Running the compiler with -source 3.6 will give you warnings; with -source 3.7 or -source future you will get the new scheme.

What’s next?

Scala 3.5.1-RC2 is already published on Maven Central. This release contains multiple fixes and small improvements merged after we branched off the 3.5.0 to focus on polishing it.

Also, the release of the next version in the LTS line is coming soon. Scala 3.3.4-RC1 is already available for testing. It contains all the forward- and backward-compatible fixes available in Scala 3.5.0.

Contributors

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

According to git shortlog -sn --no-merges 3.4.2..3.5.0 these are:

   153  Martin Odersky
    53  Eugene Flesselle
    41  Jamie Thompson
    29  Wojciech Mazur
    25  Nicolas Stucki
    22  Sébastien Doeraene
    18  noti0na1
    16  Matt Bovel
    13  Guillaume Martres
    11  Paweł Marks
    10  Hamza REMMAL
     9  Yichen Xu
     8  Jan Chyb
     7  Hamza Remmal
     7  Som Snytt
     6  Jędrzej Rochala
     5  Fengyun Liu
     5  dependabot[bot]
     3  Mikołaj Fornal
     2  Aviv Keller
     2  EnzeXing
     1  Chris Pado
     1  Filip Zybała
     1  Georgi Krastev
     1  Jisoo Park
     1  Katarzyna Marek
     1  Lucas Nouguier
     1  Lucy Martin
     1  Ola Flisbäck
     1  Pascal Weisenburger
     1  Quentin Bernet
     1  Raphael Jolly
     1  Seth Tisue
     1  Stephane Bersier
     1  Tomasz Godzik
     1  Yoonjae Jeon
     1  aherlihy
     1  rochala
     1  willerf