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
Copy file name to clipboardExpand all lines: blog/_posts/2024-02-26-scala-3.4.0-and-3.3.2-released.md
+22-12
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,9 @@ 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 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.
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 stay on the LTS line. Moreover, you can safely bump the patch version of the LTS release and benefit from the bugfixes without forcing any updates on the consumers of your library, even in regard to the patch version.
12
+
13
+
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
14
13
15
Scala 3.4.0 and 3.3.2 share most of the changes since the 3.3.1 version. The difference is that 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 binary compatibility but also full source compatibility. **We checked that every single one of over a thousand projects 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
16
@@ -36,28 +38,29 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
36
38
37
39
### Improvements to the type system and inference
38
40
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:
41
+
-Type inference for functions similar to fold is greatly improved. For example:
if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
47
+
43
48
```
44
49
45
-
can now be written more concisely as:
50
+
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
51
+
52
+
- 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:
46
53
47
54
```scala
48
-
valf: [T] =>T=>String= [T] =>x=> x.toString
55
+
valf: [T] =>T=>String= [T] =>(x: T)=> x.toString
49
56
```
50
57
51
-
- Type inference for functions similar to fold is greatly improved. For example:
58
+
can now be written more concisely as:
52
59
53
60
```scala
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
-
61
+
valf: [T] =>T=>String= [T] => x => x.toString
58
62
```
59
63
60
-
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
61
64
- The compiler now avoids generating given definitions that loop, removing a long-standing footgun in implicit resolution.
62
65
63
66
### Backend improvements
@@ -68,6 +71,7 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
68
71
### Reporting
69
72
70
73
- Scala 3.4 improves the error message when a signature from the classpath comes from an incompatible TASTy version. It has improved readability and provides a more useful diagnostic of what a user can do to fix the problem.
74
+
71
75
```
72
76
error while loading Tuple,
73
77
TASTy file /scala/Tuple.tasty could not be read, failing with:
@@ -107,7 +111,13 @@ Following syntax is now deprecated and will report warnings when used:
107
111
-`xs: _*` varargs (rewrite to `xs*`)
108
112
- trailing `_` to force eta expansion (can be just omitted)
109
113
110
-
All those rewrites will be performed automatically by the compiler if you run it with `-rewrite -source 3.4-migration` flags.
114
+
All those rewrites will be performed automatically by the compiler if you run it with `-rewrite -source 3.4-migration` flags. If you cannot make those rewrites in your codebase, you can suppress the warnings in single file by adding
0 commit comments