Skip to content

Commit 61bffbe

Browse files
committed
Polishing of 3.4.0 announcement
1 parent c80870d commit 61bffbe

File tree

1 file changed

+128
-104
lines changed

1 file changed

+128
-104
lines changed

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

Lines changed: 128 additions & 104 deletions
Original file line numberDiff line numberDiff line change
@@ -8,18 +8,34 @@ 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 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.
1212

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

1515
## What's new in 3.3.2 LTS (and 3.4.0 too)
1616

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

1919
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.
2020

2121
## Changes exclusive to 3.4.0
2222

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+
2339
- 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:
2440

2541
```scala
@@ -32,18 +48,25 @@ Another important change, not directly visible to end users, is the integration
3248
val f: [T] => T => String = [T] => x => x.toString
3349
```
3450

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

4053
```scala
41-
case '[ (t, t, t) ] => ???
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+
4258
```
4359

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+
4770
- If there is an error reading a class file, we now report the version of the classfile and a recommendation to check JDK compatibility:
4871

4972
```
@@ -56,16 +79,27 @@ Another important change, not directly visible to end users, is the integration
5679

5780
This will improve the user experience when the class file format changes unexpectedly. This feature will be backported to Scala 3.3.3.
5881
- 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:
6082

61-
```scala
62-
def partition[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
6584

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
67102

68-
will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
69103
- 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.
70104

71105
e.g.
@@ -91,15 +125,6 @@ Another important change, not directly visible to end users, is the integration
91125
```
92126

93127
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.
103128

104129
## Contributors
105130

@@ -108,81 +133,80 @@ Thank you to all the contributors who made the release of 3.4.0 and 3.3.2 LTS po
108133
According to `git shortlog -sn --no-merges 3.3.1..3.4.0` these are:
109134

110135
```
111-
474 Martin Odersky
112-
296 Nicolas Stucki
113-
132 Fengyun Liu
114-
119 Dale Wijnand
115-
77 Jamie Thompson
116-
69 Sébastien Doeraene
117-
60 Paweł Marks
118-
32 Chris Kipp
119-
27 Guillaume Martres
120-
26 Rikito Taniguchi
121-
21 Yichen Xu
122-
19 EnzeXing
123-
14 Szymon Rodziewicz
124-
13 Lucas Leblanc
125-
12 Jakub Ciesluk
126-
12 Jędrzej Rochala
127-
12 Katarzyna Marek
128-
11 Carl
129-
10 David Hua
130-
9 Florian3k
131-
9 Wojciech Mazur
132-
8 Eugene Flesselle
133-
8 ghostbuster91
134-
7 Hamza Remmal
135-
7 Jan Chyb
136-
7 Ondrej Lhotak
137-
7 Quentin Bernet
138-
6 Julien Richard-Foy
139-
6 Kacper Korban
140-
6 Seth Tisue
141-
5 Lorenzo Gabriele
142-
5 Matt Bovel
143-
5 Som Snytt
144-
5 Yuito Murase
145-
5 dependabot[bot]
146-
3 David
147-
3 Lucas
148-
3 Pascal Weisenburger
149-
3 Tomasz Godzik
150-
2 Aleksander Rainko
151-
2 Decel
152-
2 Guillaume Raffin
153-
2 Ondřej Lhoták
154-
2 Oron Port
155-
2 danecek
156-
2 rochala
157-
1 Adam Dąbrowski
158-
1 Aleksey Troitskiy
159-
1 Arnout Engelen
160-
1 Ausmarton Zarino Fernandes
161-
1 Bjorn Regnell
162-
1 Daniel Esik
163-
1 Eugene Yokota
164-
1 Fabián Heredia Montiel
165-
1 François Monniot
166-
1 Jakub Cieśluk
167-
1 John Duffell
168-
1 John M. Higgins
169-
1 Justin Reardon
170-
1 Kai
171-
1 Kisaragi
172-
1 Lucas Nouguier
173-
1 Lukas Rytz
174-
1 LydiaSkuse
175-
1 Martin Kucera
176-
1 Martin Kučera
177-
1 Matthew Rooney
178-
1 Matthias Kurz
179-
1 Mikołaj Fornal
180-
1 Nicolas Almerge
181-
1 Preveen P
182-
1 Shardul Chiplunkar
183-
1 Stefan Wachter
184-
1 philippus
185-
1 q-ata
186-
1 slim
187-
136+
474 Martin Odersky
137+
296 Nicolas Stucki
138+
132 Fengyun Liu
139+
119 Dale Wijnand
140+
77 Jamie Thompson
141+
69 Sébastien Doeraene
142+
60 Paweł Marks
143+
32 Chris Kipp
144+
27 Guillaume Martres
145+
26 Rikito Taniguchi
146+
21 Yichen Xu
147+
19 EnzeXing
148+
14 Szymon Rodziewicz
149+
13 Lucas Leblanc
150+
12 Jakub Ciesluk
151+
12 Jędrzej Rochala
152+
12 Katarzyna Marek
153+
11 Carl
154+
10 David Hua
155+
9 Florian3k
156+
9 Wojciech Mazur
157+
8 Eugene Flesselle
158+
8 ghostbuster91
159+
7 Hamza Remmal
160+
7 Jan Chyb
161+
7 Ondrej Lhotak
162+
7 Quentin Bernet
163+
6 Julien Richard-Foy
164+
6 Kacper Korban
165+
6 Seth Tisue
166+
5 Lorenzo Gabriele
167+
5 Matt Bovel
168+
5 Som Snytt
169+
5 Yuito Murase
170+
5 dependabot[bot]
171+
3 David
172+
3 Lucas
173+
3 Pascal Weisenburger
174+
3 Tomasz Godzik
175+
2 Aleksander Rainko
176+
2 Decel
177+
2 Guillaume Raffin
178+
2 Ondřej Lhoták
179+
2 Oron Port
180+
2 danecek
181+
2 rochala
182+
1 Adam Dąbrowski
183+
1 Aleksey Troitskiy
184+
1 Arnout Engelen
185+
1 Ausmarton Zarino Fernandes
186+
1 Bjorn Regnell
187+
1 Daniel Esik
188+
1 Eugene Yokota
189+
1 Fabián Heredia Montiel
190+
1 François Monniot
191+
1 Jakub Cieśluk
192+
1 John Duffell
193+
1 John M. Higgins
194+
1 Justin Reardon
195+
1 Kai
196+
1 Kisaragi
197+
1 Lucas Nouguier
198+
1 Lukas Rytz
199+
1 LydiaSkuse
200+
1 Martin Kucera
201+
1 Martin Kučera
202+
1 Matthew Rooney
203+
1 Matthias Kurz
204+
1 Mikołaj Fornal
205+
1 Nicolas Almerge
206+
1 Preveen P
207+
1 Shardul Chiplunkar
208+
1 Stefan Wachter
209+
1 philippus
210+
1 q-ata
211+
1 slim
188212
```

0 commit comments

Comments
 (0)