Back to the Future: Scala 3.1 baut Brücke zu Scala 2 und geht sonst eigene Wege

Alte Bekannte wie den Silencer @nowarn holt das Scala-Team aus der Versenkung, safer exceptions sind neu. Library Maintainer sollten mit dem Update noch warten.

In Pocket speichern vorlesen Druckansicht 17 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Silke Hahn
Inhaltsverzeichnis

Die Programmiersprache Scala ist in Version 3.1 erschienen und setzt damit das Versionierungsschema major.minor.patch um – anders als Scala 2, das noch dem Schema epoch.major.minor folgte. Somit ist Version 3.1 die erste Minor-Version nach der Hauptversion Scala 3.0. Die stabile Minor-Version hat einige neue Features im Gepäck, unter anderem die noch experimentellen safer exceptions zum Deklarieren und Prüfen, welche Ausnahmen möglich sind. Sie lassen sich optional durch den Befehl import language.experimental.saferExceptions aktivieren. Typen lassen sich anschließend mit der gewünschten Ausnahmeart kennzeichnen, die während der Evaluierung auszulösen ist: Wer hierzu genauere Informationen benötigt, wird in der Dokumentation fündig.

def f(x: Double): Double throws LimitExceeded =
  if x < limit then f(x) else throw LimitExceeded()

Ein weiteres neues Feature soll beim Matching über String-Literale den Bytecode optimieren, und die Scala-Entwickler haben das Compiler-Flag -Wconf ergänzt. Damit lassen sich Compilerwarnungen offenbar filtern und konfigurieren, beispielsweise stummschalten oder in Fehlermeldungen umwandeln. Ein Comeback feiert die aus Scala 2.13 bekannte Annotation @nowarn, die ursprünglich auf ein Silencer-Plug-in zurückgeht. Mit dieser Annotation lassen sich absehbare Warnungen direkt im Code unterdrücken, und zwar an den Stellen, an denen mit ihnen zu rechnen ist. Die wiederbelebte Annotation und das neue Compiler-Flag funktionieren der Release-Meldung zufolge großteils so, wie man es von Scala 2 her erwarten würde. Lediglich einige Filter für das Auswählen von Warnhinweisen haben sich geändert. Mehr dazu verrät die Hilfefunktion, die sich mittels Eingabe von -Wconf:help aufrufen lässt.

Weitere Neuerungen kommen der Kompatibilität mit Scala 2 zugute. So bietet der Compiler von Scala 3 neuerdings eine vereinfachte Manifestsynthese, um Instanzen für den Manifest-Trait erstellen zu können. Bei der neuen Implementierung handelt es sich dem Scala-Team zufolge um eine leicht vereinfachte Annäherung an die ursprüngliche Implementierung in Scala 2. Sie soll garantieren, dass eine Reihe von Ausdrücken, die in Scala 2 wahr waren, beim Kompilieren mit Scala 3 weiterhin wahr bleiben. Konkret garantiert ist demzufolge der Wahrheitscharakter folgender Ausdrücke:

  • manifest[A] == manifest[B]
  • manifest[A].runtimeClass == manifest[B].runtimeClass
  • optManifest[A] == optManifest[B]
  • optManifest[A].asInstanceOf[ClassTag[A]].runtimeClass == optManifest[B].asInstanceOf[ClassTag[B]].runtimeClass

Für versiegelte Hierarchien soll es nun eine Mirror-Option geben, und eine Reihe weiterer Änderungen kommt in Scala 3.1 zum Tragen. Unter anderem hat das Scala-Team die Annotation @experimental aus dem experimentellen Stadium entlassen. Ab sofort müssen User nicht länger auf den Nightly Build des Compilers zurückgreifen, um APIs als "experimentell" definieren zu können. Hierzu gibt es einen eigenen Abschnitt in der Design-Dokumentation.

Der Release-Meldung zufolge ist Scala 3.1 in den Binaries abwärtskompatibel, sodass Entwicklerinnen und Entwickler problemlos mit Scala 3.0 kompilierte Abhängigkeiten in mit Scala 3.1 erstellten Projekten weiternutzen können sollten. Scala 3.1. ist allerdings nicht aufwärtskompatibel, wie die Herausgeber betonen: So lassen sich Abhängigkeiten, die mit Scala 3.1 erstellt sind, nicht in Scala-3.0-Projekten verwenden.

Wer Anwendungen entwickelt, sollte dem Scala-Team zufolge die Compilerversion problemlos aktualisieren können. Wer hingegen Maintainer einer Library ist, zwingt durch ein Update auf Scala 3.1 alle User, das Update ebenfalls durchzuführen. Das könnte in manchen Projekten zu Unstimmigkeiten führen. Wer diesbezüglich unsicher ist, sollte nach Möglichkeit auf Scala 3.2 warten und die eigene Library vorerst nur unter der Version 3.0.2 veröffentlichen: So bleibt gewährleistet, dass auch solche Downstream-User die Library weiter verwenden können, die das Update auf Scala 3.1 zurzeit noch nicht durchführen können. Auf GitHub steht ein Build-Beispiel bereit, das sich an dieser Empfehlung orientiert.

Die Fülle aller kleinen und großen Neuerungen lässt sich dem Blogeintrag des Entwicklerteams auf der Scala-Website entnehmen. Wer es ganz genau wissen will, möge zudem einen Blick in das Changelog werfen. Die nächste Patch-Version 3.1.1. ist für Anfang Dezember 2021 geplant.

(sih)