Incompatibilities & Dropped Features

enum, export, given, then, =>> and ?=> are regular keywords in Scala 3 and cannot be identifiers any more (soft keywords such as inline, opaque, extension, using, open, transparent and infix are unaffected). The migration guide’s example is object given { val enum = ... }:

The fix is a different name or backticks around the name, and the migration rewrite chooses backticks (see the diff above, where both given and enum are quoted). A Java method with such a name, for example then, is called with the same backticks, but the practical remedy is to rename on your side.

Source: Scala 3 Migration Guide: Restricted Keywords

def print() { ... }, with no =, declared a method returning Unit in Scala 2. It was deprecated in 2.13 and is dropped in Scala 3.

Write def print(): Unit = .... The rewrite inserts : Unit = (see the diff above). Note that the form made a method return Unit whatever its body computed.

Source: Scala 3 Reference: Dropped: Procedure Syntax

A lambda parameter followed by a type must be parenthesized: { x: Int => x * x } is ambiguous with the optional-braces syntax and is rejected.

The fix is { (x: Int) => x * x }, which also compiles on 2.13, so the change can be made before the migration. The message itself tells you the rewrite switch.

Source: Scala 3 Migration Guide: Parentheses Around Lambda Parameter

A Scala 2 style that puts the argument block on the next line, after the call, is no longer parsed as an argument.

On 3.10 the brace is a new statement, and the call before it lacks its second argument list:

The migration rewrite indents the brace so that it belongs to the call; the cleaner fix is to move it up: test("my test") {. The same rewrite handles a refinement placed after a new line (type Bar = Foo followed by {).

Source: Scala 3 Migration Guide: Open Brace Indentation For Passing An Argument

Scala 3 uses indentation to find the end of a statement more strictly. In the guide’s example an indented line after a value is read as an application of that value, not a new statement:

There is no automatic rewrite; fix the indentation so that (1, 1) lines up with val. A formatter such as scalafmt prevents the mistake, but it may restyle the whole project, so adopt it as a separate commit. The rest of the indentation rules are in Optional Braces & Indentation.

Source: Scala 3 Migration Guide: Wrong indentation

Scala 2 accepted def foo[_: Foo], a type parameter named _ together with a context bound, a trick the fastparse library used. Martin Odersky called it a "clever exploit of a scalac compiler bug", and Scala 3 closes it.

Give the parameter a real name (def foo[T: Foo]). Binary compatibility is unaffected because type parameters are erased.

Source: Scala 3 Migration Guide: _ As A Type Parameter

def foo[+] named a type parameter + in Scala 2. Scala 3 reads the sign as a variance annotation and finds no name.

Choose an ordinary name. + and - remain valid as type names in general (type +), only the parameter position changed.

Source: Scala 3 Migration Guide: + And - As Type Parameters

'abc was a literal of type Symbol in Scala 2. The syntax is deprecated in 2.13 and gone in Scala 3, where ' begins a quote for metaprogramming. The class scala.Symbol itself still exists.

The rewrite produces Symbol("abc"). The migration guide recommends a second step: replace Symbol with plain strings or a dedicated class, because Symbol itself is deprecated. The message names the escape hatch import language.deprecated.symbolLiterals, which keeps old files compiling while they are being converted.

Source: Scala 3 Reference: Dropped: Symbol Literals

do now introduces the body of for, while and if in the new control syntax, so do { ... } while (cond) could not stay. The program below shows what 3.10 says:

Source: Scala 3 Reference: Dropped: Do-While

The replacements are while ({ body; cond }) (), which also compiles on Scala 2 and is what the rewrite emits, or the Scala 3 form below. The loop-and-a-half style, a while whose condition block runs the body first, is the idiom:

which prints 3. For a loop that walks a collection, prefer for or a higher-order function; see Conditionals & Loops.

Source: Scala 3 Reference: Dropped: Do-While

A method declared with an empty parameter list, def message(): String, could be called as message in Scala 2. Scala 3 requires the parentheses; Java-defined methods are exempt, because their signatures cannot express the difference.

Only the first call fails: "abc".length calls a Java method and compiles. The rewrite adds the () (println(message()) in the diff above) and Scalafix can do it on 2.13 beforehand. The convention that follows is the one the style guide gives: use () for methods with side effects and no () for pure accessors.

Source: Scala 3 Reference: Dropped: Auto-Application

Scala 3 expands a method to a function automatically (automatic eta-expansion), which makes the trailing m _ syntax unnecessary. It also stops turning a plain value into a nullary function:

The two lines differ in severity. x _ on a value is an error; the rewrite replaces it with (() => x). twice _ on a method is only a warning since Scala 3.4 (write plain twice). The migration guide lists the row as a Scala 2.13 deprecation, but 2.13.18 itself rejects x _ on an Int with _ must follow method; cannot follow Int, so in practice the row concerns method references.

Source: Scala 3 Migration Guide: Value eta-expansion

Scala 2 had an implicit conversion Predef.any2stringadd that added + to every type, so new AnyRef + "foo" compiled. It is deprecated in 2.13 and removed in Scala 3.

The replacement is an explicit conversion, String.valueOf(x) + "foo", or string interpolation (see Strings & Interpolation). The Scalafix rule fix.scala213.Any2StringAdd from scala/scala-rewrites applies it on 2.13.

Source: Scala 3 Migration Guide: any2stringadd conversion

extends { val name = "Foo" } with Bar initialized fields before the parent trait’s body. They were rarely used and mostly compensated for the lack of trait parameters, which Scala 3 now has.

Source: Scala 3 Reference: Dropped: Early Initializers

The Scala 3 form passes the value as a trait parameter:

prints 3. A trait parameter is not available in 2.13, so code that cross-compiles needs an intermediate class (abstract class BarEarlyInit(val name: String) extends Bar) or a secondary constructor. Early initializers were also used to give a subclass private state that the superclass constructor reads through an overridden method; the migration guide moves that state into a nested private object state, which is initialized on demand. Trait parameters are covered in Traits & Mixins.

Source: Scala 3 Reference: Dropped: Early Initializers

T forSome { type T } is dropped. The reference gives three reasons: it violates the soundness principle on which DOT (the calculus under Scala 3) is built, it interacts badly with other features, and it overlaps path-dependent types.

Wildcard-only existentials remain legal and are treated as refined types, so List[?] replaces List[T] forSome { type T }. When a wildcard is not enough, wrap the type in an enclosing type that carries it as a member:

When the compiler reads a Scala 2 class file that contains an existential, it approximates it and warns that a precise emulation is not possible. Wildcards are written ? since 3.4; _ still works but warns (see From warnings to errors: the 3.3 to 3.10 timeline).

Source: Scala 3 Reference: Dropped: Existential Types

@specialized made the Scala 2 compiler generate primitive-typed copies of a generic class. Scala 3 ignores the annotation (only Function and Tuple have limited specialization) and does not even warn:

prints 3. This is the one "silent" row of the table: the code compiles and runs, but the annotation has no effect, which can matter for hot paths that relied on the specialized variants. Similar benefits can come from inline methods, see Inline.

Source: Scala 3 Migration Guide: Specialized

Implicit `val`s and `def`s need an explicit result type in Scala 3; the type cannot be inferred from the right-hand side any more.

Add the type (implicit val answer: Int = 42), or better, convert it to given answer: Int = 42. The Scalafix rule ExplicitResultTypes writes the missing types on 2.13, and 2.13.18 already warns about the case with Implicit definition should have explicit type (inferred Int).

Source: Scala 3 Migration Guide: Type Of Implicit Definition

Scala 3 does not turn an implicit function value parameter ev: A => B into an implicit conversion, so the body below can no longer call print on an A.

Source: Scala 3 Migration Guide: Implicit Views

This is the first runtime incompatibility of the page. In the migration guide’s second example, where a broader implicit def anyPretty(any: Any): Pretty is in scope, the code compiles in both languages, but under -source:3.0-migration the compiler applies ev, while under the default -source:3.0 it silently applies anyPretty, which prints any. The fix is to call the conversion explicitly, ev(a).print, or to turn the parameter into a real conversion with using:

The output is <7>. The compiler’s migration mode warns about these sites but does not rewrite them.

Source: Scala 3 Migration Guide: Implicit Views

A <% B was shorthand for "an implicit conversion from A to B exists". It was deprecated for years and is removed.

The diagnostic suggests a context bound, but that would change the method’s signature. The binary-compatible fix keeps the same erased signature by writing the conversion out as an implicit parameter and calling it:

which prints 5 (an Int converts to Long by numeric widening). implicit ev is also fine on 2.13 and 3. Beware the runtime incompatibility just described. A conversion that is not meant to be implicit should become an ordinary type class, see Type Classes.

Source: Scala 3 Migration Guide: View Bounds

When two implicit conversions exist, one from Boolean and one from => Boolean, Scala 2.13 preferred the by-value one. Scala 3 reports an ambiguity.

The temporary fix is to name the conversion, boolFoo(true).foo(), which prints foo. The lasting fix is to delete the by-name overload or to replace both with one extension method.

Source: Scala 3 Migration Guide: Ambiguous Conversion On A And ⇒ A

An identifier used inside a class can name a member of an enclosing scope or an inherited member of the same name. Scala 2 silently preferred the inherited one, which depends on the parent’s code. Scala 3 asks you to say which.

The same error appears on 3.3.8 and 3.9.0. The rewrite writes println(this.x) (inherited) and B.x is the outer one. Choose deliberately: the rewrite assumes the Scala 2 meaning.

Source: Scala 3 Migration Guide: Inheritance Shadowing

A constructor declared private[foo] in a private class leaks the private class in its own type signature.

Since the class is private, make the constructor private too. The migration guide says migration mode only warns about it; there is no automatic rewrite.

Source: Scala 3 Migration Guide: Non-private Constructor In Private Class

Re-declaring an inherited concrete method as abstract in a subtrait did nothing in Scala 2; in Scala 3 the subtrait’s version wins and subclasses must implement it.

Delete the abstract def in B; it had no effect on 2.13. The decision is recorded in Dotty issue 4770.

Source: Scala 3 Migration Guide: Abstract Override

In Scala 2 the companion object of a case class extended FunctionN, so Foo.tupled, Foo.curried and Foo.andThen existed. Scala 3 companions do not extend those traits.

Source: Scala 3 Migration Guide: Case Class Companion

Give the constructor a function type explicitly:

Output: Foo(1,true) and Foo(2,false). The guide’s alternative (Foo.apply _).curried(1)(true) also cross-compiles but now carries the trailing-underscore warning. A named function value allocates once, which helps hot paths. See Case Classes.

Source: Scala 3 Migration Guide: Case Class Companion

The synthetic unapply of a case class returned Option[(A, B)] in Scala 2; Scala 3 returns the case class itself (the extractor is option-less, which avoids an allocation). Pattern matching is unaffected, and so are user-written extractors. Only a direct call changes:

Source: Scala 3 Migration Guide: Explicit Call to unapply

A pattern binding replaces the call:

The output is (1.5,2.5) and Location(3.0,4.0), the second line showing that unapply now returns its argument. More on extractors in Extractors & Pattern Bindings.

Source: Scala 3 Migration Guide: Explicit Call to unapply

The getter and setter that @BeanProperty generates exist in the bytecode (for Java frameworks) but are invisible to Scala 3 source.

Use the idiomatic accessor, pojo.fooBar = "hello". The accessors are still generated, which a reflection listing of the class confirms:

prints hello and getFooBar, setFooBar. Java code that uses the JavaBeans naming sees them as before; see Calling Scala from Java.

Source: Scala 3 Migration Guide: Invisible Bean Property

A by-name type cannot instantiate a type parameter. The standard library function Function.uncurried has such a case:

The fix depends on the situation: write your own uncurried with the by-name signature, or inline its two-line body.

Source: Scala 3 Migration Guide: ⇒ T as Type Argument

Scala 3 cannot reduce the application of an abstract higher-kinded type member to a wildcard.

Source: Scala 3 Migration Guide: Wildcard Type Argument

Both messages appear: the _ deprecation of 3.4 and the real error. Replace the wildcard with a type parameter (def f[A](foo: Foo[A])). When the member is itself an argument, as in Seq[Foo[_]], wrap it: class FooWrapper[A](foo: Foo[A]) and use Seq[FooWrapper[?]]. That fixed version compiles on 3.10:

Source: Scala 3 Migration Guide: Wildcard Type Argument

Scala 2 did not check default arguments and inner classes for variance.

Source: Scala 3 Migration Guide: Unsoundness Fixes in Variance checks

Each case needs care. The usual options are to make A invariant, to add a bound on B, or to add an overload instead of a default. Applying two of them:

It prints List(1, 2) and b. As a stop-gap, @uncheckedVariance silences the check, but the unsoundness stays. Variance itself is the subject of Variance.

Source: Scala 3 Migration Guide: Unsoundness Fixes in Variance checks

A pattern on two values can bind them to different type arguments of the same generic class. Scala 3 refuses to treat them as the same.

Source: Scala 3 Migration Guide: Unsoundness Fixes in Pattern Matching

The compiler is right: nothing proves both Fetch values share a type argument. Relax the signature so that the argument types may differ as long as they have a common ancestor:

With that change, combineReq(Fetch(Set(1)), Fetch(Set("a"))) returns Fetch(Set(1, a)) (a Set[Int | String]), the case the old signature could never type-check. A cast would also compile but only moves the failure to run time.

Source: Scala 3 Migration Guide: Unsoundness Fixes in Pattern Matching

When an overriding method has no declared type, Scala 2.13 infers it from the right-hand side. Scala 3 takes it from the overridden method.

Child#foo returns RichFoo on 2.13 and Foo on 3. Declaring override def foo: RichFoo keeps the 2.13 meaning, and the program then prints rich. This is the second quiet change that can be a runtime difference (implicit conversions and casts could pick another path), so public overrides should always state their type.

Source: Scala 3 Migration Guide: Return Type of an Override Method

Scala 2 inferred a structural type for new { def bar = ... } and allowed foo.bar through reflection (with import scala.language.reflectiveCalls). Scala 3 infers Object for the anonymous class.

The fix is to write the structural type: val foo: { def bar: Int } = new { def bar: Int = 7 }. The program then prints 7, but with -deprecation the call produces a warning: method reflectiveSelectableFromLangReflectiveCalls in object Selectable is deprecated since 3.0: import scala.reflect.Selectable.reflectiveSelectable instead of scala.language.reflectiveCalls. Import scala.reflect.Selectable.reflectiveSelectable instead. Structural types, Selectable and Dynamic have their own page, Structural Types, Selectable & Dynamic.

Source: Scala 3 Migration Guide: Reflective Type

The special handling of DelayedInit is gone. DelayedInit still exists and is deprecated since 2.11.0, but a class that extends it no longer has its constructor body passed to delayedInit:

Source: Scala 3 Reference: Dropped: DelayedInit

It compiles with a deprecation warning, and prints only running; in Scala 2 it printed before first. The consequence that surprises people is App, which was built on DelayedInit. The reference says it is "partially broken", and on 3.10 App is itself deprecated, since 3.8.0:

Source: Scala 3 Reference: Dropped: DelayedInit

Two real consequences: the body runs in the object’s static initializer (on some JVMs it is only interpreted, so never benchmark inside an App), and args is null there, so reading it crashes. An App that never reads args still runs (a variant printing started ran fine). The replacements are @main or an explicit main:

With the arguments ada grace this prints 2 names: ada, grace. An object Hello { def main(args: Array[String]) } run with three arguments prints args = 3. See Hello World & @main Methods.

Source: Scala 3 Reference: Dropped: DelayedInit

T#A is only legal when T is a concrete type. On an abstract type, type parameter or alias to one, it is unsound (combined with other Scala 3 features) and it rules out the type-level encoding of a combinator calculus.

The Outer#In projection on the concrete class compiles. For abstract prefixes, use a path-dependent type (def get(h: Holder)(a: h.A): h.A) or an implicit parameter. The same rule explains why type lambdas written with the Scala 2 projection trick are unnecessary now: see Type Lambdas & Higher Kinds.

Source: Scala 3 Reference: Dropped: General Type Projection

The reference page says package objects "will be dropped", but they are only slated: they still work on 3.10, without a warning even under -deprecation.

prints max grade 6. The Scala 3 form is a top-level definition, in any file of the package. The compiler wraps top-level definitions in a synthetic object named after the file (src$package), so renaming such a file changes the binary name of what it contains. The 3.10 release notes say there is no concrete plan to remove package objects, and SIP-68, which lets referenceable package objects behave regularly, is a preview feature in 3.10. See Packages, Imports & Top-Level Definitions.

Source: Scala 3 Reference: Dropped: Package Objects

An inner class cannot have the same name as an inner class of its parent. In Scala 2 the two looked like an override but classes cannot be overridden.

Rename one of the classes.

Source: Scala 3 Reference: Dropped: Class Shadowing

Function types and tuples are no longer limited to 22 parameters or fields. Beyond 22 they erase to scala.runtime.FunctionXXL and scala.runtime.TupleXXL, implemented with arrays. A 23-field tuple and a 23-parameter function, generated by script, compile and run:

The output is 23, 23 and 23. This is a removal of a limit, not an incompatibility, but code that worked around it with nested tuples can now be flattened. See Tuples & Named Tuples.

Source: Scala 3 Reference: Dropped: Limit 22

Inline XML (<a>b</a>) in Scala source is on its way out: the reference says literals "will be dropped in the near future" in favor of string interpolation. On 3.10 they still parse, but the compiler needs the scala-xml library and reports a missing package otherwise:

With //> using dep org.scala-lang.modules::scala-xml:2.4.0 the program val x = <peak><name>{name}</name></peak> prints <peak><name>Pico</name></peak>. The hint printed by Scala CLI at that point recommended 2.5.0, which was the newest version on Maven Central at the check date. New code should build documents with scala.xml constructors, a template library or the string interpolators of an XML library.

Source: Scala 3 Reference: Dropped: XML Literals

Scala 2 used weak conformance to widen numeric types, so List(n, c, d) with an Int, a Char and a Double was a List[Double]. Scala 3 keeps one rule: an Int literal adapts to another numeric type when needed.

Without the last assignment the program prints List(1.0, 2.0, 0.0, -3.3): the literal 0 adapts to Double. On 3.10 the type of the mixed list is the union List[Int | Char | Double], not even List[AnyVal] as the reference says (the exact printed type is more precise than the documentation). Add a type ascription or convert the values (n.toDouble).

Source: Scala 3 Reference: Dropped: Weak Conformance

A return inside a lambda used to unwind through an exception, NonLocalReturnException, with a hidden cost and a leaky failure mode (a catch of Exception would intercept it). It is deprecated since 3.2.0 and warns on 3.10 without any flag:

Source: Scala 3 Reference: Deprecated: Nonlocal Returns

The replacement is scala.util.boundary, which also replaces the Breaks API. It is explicit, lexically scoped and checked by the compiler:

The output is 1 and -1. See Exceptions, boundary & Early Exit.

Source: Scala 3 Reference: Deprecated: Nonlocal Returns

The compiler now infers that a private member only accessed through this is object-private, which was the purpose of private[this]. The qualified form is deprecated, and protected[this] is dropped without replacement. On 3.10 the old form compiles with a warning:

The rewrite drops the qualifier. The subtle part is the second runtime incompatibility: a private val that is only used through this and by no method may no longer generate a field, so reflection that expected the field fails. The fix is the qualified form with the class as qualifier, private[C] val field = x + 1. Class parameters declared private val keep their fields and variance checks.

Source: Scala 3 Reference: Dropped: private[this and protected[this]]

var x: A = _ declared an uninitialized field. The marker is now a value in scala.compiletime:

The output is (0,null). The old = _ compiles with the warning = _ has been deprecated; use = uninitialized instead and is rewritten by -source:3.4-migration.

Source: Scala 3 Reference: Dropped: Wildcard Initializer

The Scala 2 compound type has been deprecated in favor of & since 3.4. On 3.10:

The identical file on 3.9.0 reports two warnings under the same code E003, and 3.3.8 compiles silently. In a typed pattern the intersection needs parentheses, case y: (A & B); the rewrite adds them. with remains valid in class C extends A with B (a different construct). The 3.10 release notes name this among the removed legacy features that end cross-compilation between Scala 2 and 3.10.

Source: Scala 3.10 release notes: A with B is an error

The remaining items of the 3.4 list (_ type wildcards, xs: _*, private[this], var x = _ and the trailing _) are all fixed at once by -source:3.4-migration -rewrite. Applied to a class with those forms it produces exactly:

The compiler reported six warnings and patched the file. A later flag does not replay an earlier one, so the migration to a newer LTS is a sequence of -source:3.4-migration, 3.5-migration and so on. That recipe is on Upgrading Between Scala 3 Versions.

Source: Scala 3.9 release notes: Migration guide

A generator pattern that is narrower than the type of the source needs an explicit case, because an implicit filter hid data loss:

The same line is only a warning on 3.3.8 and is an error on 3.9.0 and 3.10.0. for case Some(x) <- xs yield x returns List(1, 3). The mechanics of generators are in For Comprehensions.

Source: Scala 3.9 release notes

When the compiler looks for an implicit in a type’s companion it now only considers instances accessible at the call site.

3.3.8 prints configured silently; 3.9.0 prints it with a deprecation warning under -deprecation: Usage of implicit given instance given_Config defined in object Config, which is not accessible here. In Scala 3.10, this implicit will no longer be found. The library-side fix is a public companion or a given in a public object. Users usually cannot work around it, so publish the fix before your consumers move to 3.10.

Source: Scala 3.10 release notes: Inaccessible companion implicits are no longer found

Before 3.10, val self = this at the top of a file resolved to the synthetic package object of the file. That was almost never intended:

It compiles on 3.9.0 and 3.3.8. Remove the reference or move the definition into an object.

Source: Scala 3.10 release notes: this is illegal in top-level definitions

The standard a -> b pair syntax became an inline extension method on 3.10, and Predef.ArrowAssoc stopped being an implicit conversion. That can silently change which -> runs. A DSL that defines -> through an implicit class loses to the standard one:

On 3.10.0 this prints the tuple (1,a). The same file prints custom(1, a) on 3.9.0 and 3.3.8. No error, no warning: the program compiles and the meaning changes. The version defined as an extension method keeps its priority and prints custom(1, a) on 3.10 when dsl.* is imported. So a DSL that ships its own -> has to be rewritten as an extension. See Domain Specific Languages.

Using the old names directly produces deprecation warnings, both since 3.10.0:

Ordinary uses (1 to 3, 3.max(4), 5.abs) are unaffected. Macros and compiler plugins that inspect the old Rich* trees must match the new shape.

Source: Scala 3.10 release notes: → is an inline extension method

Two checks that Scala 3 introduced are not errors by default on 3.10. An alphanumeric method that is not declared infix and is used as an infix operator warns by default since 3.4 (3.3.8 accepts it silently), and the warning becomes an error only under -source:future. The Matchable constraint on a type test of an Any value is silent by default and warns only under -source:future. The program:

Source: Scala 3 Reference: Rules for Operators and Scala 3 Reference: The Matchable Trait

Compiled as it is, it prints 3 twice after one warning:

With //> using options -source:future the same use is an error, and both type tests warn:

Declare such methods infix and keep values in a Matchable-typed variable, to be ready for the day these become the default. The infix warning is also covered, with the style guide’s view of it, on Style Guide. See Type Hierarchy & Matchable.

Source: Scala 3 Reference: Source Compatibility