Skip to content

Commit 93b89d8

Browse files
committed
More polish on 3.4 announcement
1 parent 8f1067a commit 93b89d8

File tree

1 file changed

+22
-12
lines changed

1 file changed

+22
-12
lines changed

blog/_posts/2024-02-26-scala-3.4.0-and-3.3.2-released.md

+22-12
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,9 @@ We are thrilled to announce the release of two versions of Scala 3: the first ve
88

99
## ... so which version should I update to?
1010

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.
1214

1315
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.
1416

@@ -36,28 +38,29 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
3638

3739
### Improvements to the type system and inference
3840

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:
4042

4143
```scala
42-
val f: [T] => T => String = [T] => (x: T) => x.toString
44+
def partition[T](xs: List[T], pred: T => Boolean) =
45+
xs.foldRight((Nil, Nil)): (x, p) =>
46+
if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
47+
4348
```
4449

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:
4653

4754
```scala
48-
val f: [T] => T => String = [T] => x => x.toString
55+
val f: [T] => T => String = [T] => (x: T) => x.toString
4956
```
5057

51-
- Type inference for functions similar to fold is greatly improved. For example:
58+
can now be written more concisely as:
5259

5360
```scala
54-
def partition[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+
val f: [T] => T => String = [T] => x => x.toString
5862
```
5963

60-
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
6164
- The compiler now avoids generating given definitions that loop, removing a long-standing footgun in implicit resolution.
6265

6366
### Backend improvements
@@ -68,6 +71,7 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
6871
### Reporting
6972

7073
- 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+
7175
```
7276
error while loading Tuple,
7377
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:
107111
- `xs: _*` varargs (rewrite to `xs*`)
108112
- trailing `_` to force eta expansion (can be just omitted)
109113

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
115+
116+
```scala
117+
import scala.language.`3.3`
118+
```
119+
120+
or globally using the `-source 3.3` flag.
111121

112122
### Other source compatibility concerns
113123

0 commit comments

Comments
 (0)