You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -8,18 +8,34 @@ We are thrilled to announce the release of two versions of Scala 3: the first ve
8
8
9
9
## ... so which version should I update to?
10
10
11
-
Scala 3.4.0 and 3.3.2 share most of the changes since the 3.3.1 version. The difference Scala 3.4.0 adds new features and deprecates legacy mechanisms, while version 3.3.2 is focused solely on bug fixes and usability improvements. What's more, 3.3.2 maintains not only full output compatibility but also full source compatibility. **This means that every single one from over a thousand projects we checked that worked with 3.3.1 still work with 3.3.2.** To achieve this, we had to be extra careful with selecting changes for that release. Thus, not every bug that is fixed in 3.4.0 is also fixed in 3.3.2. Some of the not-ported changes might still land in 3.3.3.
11
+
Scala 3.4.0 code can use dependencies compiled with Scala 3.3.x, but not the other way around. That means that if you are a library author, you should consider staying on the LTS line. If you are working on a project that is not meant to be used as an external dependency, feel free to update to Scala 3.4.0, especially if you are starting a new project.
12
12
13
-
Scala 3.4.0 code can depend on dependencies compiled with Scala 3.3.x, but not the other way around. That means that if you are a library author, you should consider staying on the LTS line. If you are working on a project that is not meant to be used as an external dependency, feel free to update to Scala 3.4.0, especially if you are starting a new project.
13
+
Scala 3.4.0 and 3.3.2 share most of the changes since the 3.3.1 version. The difference Scala 3.4.0 adds new features and deprecates legacy mechanisms, while version 3.3.2 is focused solely on bug fixes and usability improvements. What's more, 3.3.2, as a part of the LTS line, maintains not only full output compatibility but also full source compatibility. **This means that every single one from over a thousand projects we checked that worked with 3.3.1 still work with 3.3.2.** To achieve this, we had to be extra careful with selecting changes for that release. Thus, not every bug that is fixed in 3.4.0 is also fixed in 3.3.2. Some of the not-ported changes might still land in 3.3.3.
14
14
15
15
## What's new in 3.3.2 LTS (and 3.4.0 too)
16
16
17
-
If you go through the release notes of Scala [3.3.2 LTS](https://github.com/lampepfl/dotty/releases/tag/3.3.2) and [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0), you can see a lot of bug fixes. One area that received special attention in that regard was coverage support. With most pains fixed, we are now confident in the state of coverage.
17
+
If you go through the release notes of Scala [3.3.2 LTS](https://github.com/lampepfl/dotty/releases/tag/3.3.2), you can see a lot of bug fixes. One area that received special attention in that regard was coverage support. With most pains fixed, we are now confident in the state of coverage.
18
18
19
19
Another important change, not directly visible to end users, is the integration of the presentation compiler into the compiler itself. This makes building tooling easier and allows for a more stable and reliable user experience when using Metals.
20
20
21
21
## Changes exclusive to 3.4.0
22
22
23
+
Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) contains a lot of substantial changes in improvements. Most noteworthy of them can be grouped in a few broad categories.
24
+
25
+
### Stabilized SIPs
26
+
27
+
-[SIP-54](https://docs.scala-lang.org/sips/multi-source-extension-overloads.html) is now a standard feature. It allows for importing extension methods with the same name from different sources.
28
+
-[SIP-53](https://docs.scala-lang.org/sips/quote-pattern-type-variable-syntax.html) is now a standard feature. It allows for more expressive type patterns in quotes. For example:
29
+
30
+
```scala
31
+
case'[ (t, t, t) ] =>???
32
+
```
33
+
34
+
will match any 3-element tuple, and `t` will be the greatest lower bound of types of all three elements.
35
+
- Match types are now properly specified, and thanks to that, they work in a more predictable and stable way. See [SIP-56](https://docs.scala-lang.org/sips/match-types-spec.html)
36
+
37
+
### Improvements to the type system and inference
38
+
23
39
- It is now possible to write a polymorphic lambda without writing down the types of its value parameters as long as they can be inferred from the context, for example:
24
40
25
41
```scala
@@ -32,18 +48,25 @@ Another important change, not directly visible to end users, is the integration
32
48
valf: [T] =>T=>String= [T] => x => x.toString
33
49
```
34
50
35
-
- Polymorphic lambdas are now implemented using JVM lambdas when possible instead of anonymous classes, which will make them more efficient.
36
-
- Match types are now properly specified, and thanks to that, they work in a more predictable and stable way. See [SIP-56](https://docs.scala-lang.org/sips/match-types-spec.html)
37
-
-[SIP-54](https://docs.scala-lang.org/sips/multi-source-extension-overloads.html) is now a standard feature. It allows for importing extension methods with the same name from different sources.
38
-
-[SIP-53](https://docs.scala-lang.org/sips/quote-pattern-type-variable-syntax.html) is now a standard feature. It allows for more expressive type patterns in quotes. For example:
51
+
- Type inference for functions similar to fold is greatly improved. For example:
39
52
40
53
```scala
41
-
case'[ (t, t, t) ] =>???
54
+
defpartition[T](xs: List[T], pred: T=>Boolean) =
55
+
xs.foldRight((Nil, Nil)): (x, p) =>
56
+
if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
57
+
42
58
```
43
59
44
-
will match any 3-element tuple, and `t` will be the greatest lower bound of types of all three elements.
45
-
- An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code.
46
-
-`-experimental` compiler flags will mark all top-level definitions as `@experimental`. This means that the experimental language features and definitions can be used in the project. Note that this does not change the strong guarantees of the stability of the non-experimental code. The experimental features can only be used in an experimental scope (transitively). In 3.5, we plan to allow using this flag also in the stable releases of the compiler.
60
+
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
61
+
- The compiler now avoids generating given definitions that loop, removing long-standing footgun of implicit resolution.
62
+
63
+
### Backend improvements
64
+
65
+
- Polymorphic lambdas are now implemented using JVM lambdas when possible instead of anonymous classes, which will make them more efficient.
66
+
- JVM Backend parallelization has been ported from Scala 2 to Scala 3. Read more in the discussion under [the original PR](https://github.com/scala/scala/pull/6124).
67
+
68
+
### Reporting
69
+
47
70
- If there is an error reading a class file, we now report the version of the classfile and a recommendation to check JDK compatibility:
48
71
49
72
```
@@ -56,16 +79,27 @@ Another important change, not directly visible to end users, is the integration
56
79
57
80
This will improve the user experience when the class file format changes unexpectedly. This feature will be backported to Scala 3.3.3.
58
81
- Progress reporting of compilation is now visible in IDEs. Metals IDE users will notice that compilation progress is no longer frozen at 0% when using sbt or bloop as the BSP server. IntelliJ will also correctly report progress for BSP and sbt based projects
59
-
- Type inference for functions similar to fold is greatly improved. For example:
60
82
61
-
```scala
62
-
defpartition[T](xs: List[T], pred: T=>Boolean) =
63
-
xs.foldRight((Nil, Nil)): (x, p) =>
64
-
if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
83
+
### Experimental changes
65
84
66
-
```
85
+
- An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code. Originaly it was presented in [SIP-52](https://docs.scala-lang.org/sips/binary-api.html).
86
+
-`-experimental` compiler flags will mark all top-level definitions as `@experimental`. This means that the experimental language features and definitions can be used in the project. Note that this does not change the strong guarantees of the stability of the non-experimental code. The experimental features can only be used in an experimental scope (transitively). In 3.5, we plan to allow using this flag also in the stable releases of the compiler.
87
+
88
+
### Legacy syntax depreacations
89
+
90
+
Following syntax is now deprecated and will report warnings when used:
91
+
92
+
-`_` type wildcards (rewrite to `?`)
93
+
-`private[this]` (rewrite to `private`)
94
+
-`var x = _` (rewrite to `var x = scala.compiletime.uninitialized`)
95
+
-`with` as a type operator (rewrite to `&`)
96
+
-`xs: _*` varargs (rewrite to `xs*`)
97
+
- trailing `_` to force eta expansion (can be just ommitted)
98
+
99
+
All those rewrites will be performed automatically by the compiler if we run it with `-rewrite -source 3.4-migration` flags.
100
+
101
+
### Other source compatibility concerns
67
102
68
-
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
69
103
- Refutable patterns (i.e., patterns that might not match) in a for-comprehension generator must now be preceded by `case`, or an error is reported.
70
104
71
105
e.g.
@@ -91,15 +125,6 @@ Another important change, not directly visible to end users, is the integration
91
125
```
92
126
93
127
alternatively, the definition can be changed to `transparent inline`, but as this is a TASTy breaking change, it is not a default recommendation. (Also, `inline` should be preferred when possible over `transparent inline` for reduced binary size)
94
-
- JVM Backend parallelization has been ported from Scala 2.13 to Scala 3.
95
-
- The compiler now avoids generating given definitions that loop, removing long-standing footgun of implicit resolution.
96
-
97
-
### Road to Pipelined Builds
98
-
99
-
We made the next concrete preparation for introducing pipelined Scala 3 builds. Now TASTy can store outline signatures and, additionally, the signatures of Java source files. This is the only TASTy breaking change required to introduce pipelining, which means that once it is ready, pipelined build support will be able to be released in an upcoming patch version of Scala Next.
100
-
101
-
- outline signatures (enabled with the `OUTLINEattr` TASTy attribute) only store what is necessary for separate compilation (i.e., method bodies can be elided). This will enable in the future the possibility of a faster type checking phase because a lot of work is no longer necessary to produce this outline TASTy. Elided expressions are represented by the new `ELIDED` tree in TASTy.
102
-
- Java signatures (enabled with the `JAVAattr` TASTy attribute) can be produced faster than waiting for class files from `javac`, which will be necessary to enable pipelined builds that include Java sources.
103
128
104
129
## Contributors
105
130
@@ -108,81 +133,80 @@ Thank you to all the contributors who made the release of 3.4.0 and 3.3.2 LTS po
108
133
According to `git shortlog -sn --no-merges 3.3.1..3.4.0` these are:
0 commit comments