Language Evolution: SIPs, Preview & Experimental

The official list (checked 2026-10-16) marks every completed SIP as Shipped, including the three previews of 3.10. The table covers the Scala 3-era proposals; the older ones (SIP-11 string interpolation, SIP-13 implicit classes, SIP-14 futures and promises, SIP-15 value classes, SIP-17 Dynamic, SIP-18 modularizing language features, SIP-23 literal types, SIP-25 trait parameters, SIP-27 trailing commas, SIP-30 @static, SIP-31 by-name implicit arguments, SIP-33 infix type precedence, SIP-35 opaque types and the historical SID documents) describe features that were already part of Scala 2 or of the first Scala 3 releases. The release in the second column comes from the release notes of each version.

Four SIPs in that list show the lifecycle at work. SIP-61, SIP-68, SIP-74 and SIP-75 are accepted and shipped as previews in 3.10, and will become standard in a later minor release; SIP-74 even states that it "will be activated by default in the next minor release". The sibling pages Incompatibilities & Dropped Features and Upgrading Between Scala 3 Versions cover the removals that travel with the same releases.

Source: List of all SIPs

An experimental member may not override a non-experimental one, because that would make an experimental signature visible through a stable type and break binary compatibility by accident:

Source: Scala 3 Reference: Experimental definitions, overriding

Test code is the one place where the rule is relaxed deliberately: a test framework finds tests by reflection, so tests can be marked @experimental without making the test class experimental to its callers.

-experimental allows every experimental feature in the whole project, and it does so by adding @experimental to every top-level definition. The consequence for library authors was checked with two Scala CLI projects. A library with one function was compiled with //> using option -experimental and packaged as a JAR; an application that does not use the flag then calls it:

Source: Scala 3 Reference: Experimental definitions, the -experimental compiler flag

The function in the library does not use any experimental feature; the flag alone made it experimental. So a library published with -experimental can be used only by projects that are also experimental. Applications can use the flag freely; libraries should not.

The object scala.language.experimental holds one entry per feature that has ever been experimental. The table lists the 26 nested members, plus the plain value macros, of the 3.10.0 standard library, read by reflection, and what the compiler does when each is imported. The "graduated" members stay in the library so that old code keeps compiling; importing them now produces a deprecation warning. On Scala 3.9.0 the same imports compile without warnings, which is a quick way to tell which line you are on.

Four of the experimental imports are new in 3.10 compared with 3.9.0, found by comparing the nested members of the two standard libraries: dedentedStringLiterals, inlineTraits, magic and specializedTraits. The remaining 22 are present on both lines. One of them, safe, switches on safe mode, which rejects code that calls methods tagged @rejectSafe. A program that imports it and then calls println is rejected at its first call, which is exactly its purpose:

Source: scala.language.experimental API, Scala 3 Reference: Experimental features

A case can be followed by a nested match introduced by if. The nested cases are tested only if the outer pattern matches, they can use variables bound by it, and they need not be exhaustive: when none matches, matching continues with the next outer case. That removes the usual duplicated default case.

The third call shows the fall-through: Pass matches Some(x), but no nested case accepts a hard grade with a 300 m ascent, so the match continues with case _. Without the import the compiler does not know the syntax and reports errors such as "'=>' expected, but 'case' found" at the second outer case. A similar form is described on Pattern Matching.

Source: Scala 3 Reference: Match expressions with sub cases

SIP-72 adds a ''' string whose leading indentation is removed by the language instead of by stripMargin. The opening delimiter must be followed by a newline, and the closing one must be on its own line; the newline after the opener, the final newline and the indentation up to the closing delimiter are removed.

The 26 characters are the two lines and the newline between them, with no indentation and no trailing newline. Without the import the same file does not compile: the ''' is read as a character literal and the compiler reports "empty character literal" followed by "unclosed character literal". Triple-quoted strings (""") with stripMargin remain the portable choice; see Strings & Interpolation.

Source: Scala 3 Reference: Dedented string literals

With genericNumberLiterals, a literal that has a fully defined expected type with a scala.util.FromDigits given is converted through it, with no size limit. Without the import the first line below is rejected with "number too large".

Source: Scala 3 Reference: Numeric literals

multiSpreads lifts the rule that a spread argument xs* must come last. Without the import the compiler reports "spread operator * not allowed here; must come last in a parameter list":

Source: Scala API: scala.language.experimental.multiSpreads

modularity includes the tracked modifier, which keeps a class parameter’s precise type visible to callers. Without the import tracked val name: String is a syntax error ("':' expected, but 'val' found"); with it the program below runs:

The same sub-cases program also runs with the option form, scala run Sub.scala --scalac-option -language:experimental.subCases, which prints the same four lines. On Scala 3.9.0 the imports multiSpreads and subCases exist and compile as well; dedentedStringLiterals, inlineTraits and specializedTraits do not exist there.

Source: Scala 3 Reference: Numeric literals, Scala 3 Reference: Modularity improvements

SIP-75 allows a lambda to follow a : on the same line. The lambda extends to the end of the line. SIP-74 allows a single case clause, a one-case partial function, inside parentheses. Both are accepted together with curried multi-line lambdas (fun: (x: Int) => y => followed by an indented body). First what happens without the flag:

Source: Scala 3 Reference: Relaxed lambda syntax

With //> using option -preview all of the preview forms work:

One limit is easy to hit. The single-line form does not apply when the code is immediately enclosed in parentheses, because there x: Int => Int has always meant type ascription. Putting the lambda directly inside println(...) therefore fails even with the flag on, with a misleading message:

The fix is the usual one: bind the call to a val first, as in the example above, or pass an ordinary function literal. A one-case partial function inside the parentheses of the call, as in collect(case ...), is allowed, which is what SIP-74 adds. On Scala 3.9.0 the same file fails in the same way with or without -preview, because on that line the feature is still the experimental relaxedLambdaSyntax import: with import scala.language.experimental.relaxedLambdaSyntax the map: m => m * 3 and the parenthesized collect(case (a, b) if b > 2 => a) forms compiled and ran on 3.9.0 as well, printing List(360, 1020, 285) and List(3).

Source: Scala 3 Reference: Relaxed lambda syntax, SIP-75, SIP-74

A package object could not be used as a value: network below is a package, and writing it as an expression failed with "package is not a value". Under -preview, a.b where b is a package that contains a package object expands to a.b.package.

With //> using option -preview the program prints 12. The expansion applies only when the package is used on its own, not as part of a longer selection such as network.trailCount, which always worked. On Scala 3.9.0 the program ran with import scala.language.experimental.packageObjectValues instead. The fact that package objects need a value form at all is a sign of the deprecation covered in Packages, Imports & Top-Level Definitions.

Source: Scala 3 Reference: Reference-able package objects, SIP-68

@unroll generates forwarders so that adding a defaulted parameter to a method does not break callers compiled against the older signature. The mechanism and the MiMa results are on Versions, Compatibility & JDKs, and the Java view (overloads for each prefix) on Calling Scala from Java. Here is what the lifecycle looks like. This program was run on 3.10.0:

The reference says the feature is "available under -preview since Scala 3.10.0", yet on 3.10.0 as run here the program compiled and generated the two forwarders, with three methods in total, without the flag, and the output was the same with //> using option -preview. Pass -preview anyway so that the file documents its dependency and keeps building if the gate is enforced later. On 3.9.0 the same file stops:

That is the whole lifecycle in one definition: scala.annotation.unroll is annotated @experimental in 3.9 and preview in 3.10.

Source: Scala 3 Reference: Automatic parameter unrolling, SIP-61

The reference states that a definition compiled in preview mode is not itself marked preview. This was checked the same way as the -experimental case: a library function written with the single-line lambda form was compiled with //> using option -preview and packaged; an application without the flag called it:

The consumer compiled and ran. The standard library’s own preview APIs are marked with an internal annotation, @preview, whose rules mirror @experimental: they can be referenced only from a unit compiled with -preview. It is reserved for the standard library, so application code does not use it.

Source: Scala 3 Reference: Preview definitions