Add 3.4.0 blogpost

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

@@ -0,0 +1,212 @@
+---
+layout: blog-detail
+post-type: blog
+by: Paweł Marks, VirtusLab
+title: Scala 3.4.0 and 3.3.2 LTS released!
+---
+We are thrilled to announce the release of two versions of Scala 3: the first version in the 3.4 minor line, and a patch version in the Long Term Support line.
+
+## ... so which version should I update to?
+
+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.
+
+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.
+
+## What's new in 3.3.2 LTS (and 3.4.0 too)
+
+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.
+
+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.
+
+## Changes exclusive to 3.4.0
+
+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.
+
+### Stabilized SIPs
+
+- [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.
+- [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:
+
+  ```scala
+  case '[ (t, t, t) ] => ???
+  ```
+
+  will match any 3-element tuple, and `t` will be the greatest lower bound of types of all three elements.
+- 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)
+
+### Improvements to the type system and inference
+
+- 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:
+
+  ```scala
+  val f: [T] => T => String = [T] => (x: T) => x.toString
+  ```
+
+  can now be written more concisely as:
+
+  ```scala
+  val f: [T] => T => String = [T] => x => x.toString
+  ```
+
+- Type inference for functions similar to fold is greatly improved. For example:
+
+  ```scala
+  def partition[T](xs: List[T], pred: T => Boolean) =
+     xs.foldRight((Nil, Nil)): (x, p) =>
+       if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
+
+  ```
+
+  will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
+- The compiler now avoids generating given definitions that loop, removing long-standing footgun of implicit resolution.
+
+### Backend improvements
+
+- Polymorphic lambdas are now implemented using JVM lambdas when possible instead of anonymous classes, which will make them more efficient.
+- 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).
+
+### Reporting
+
+- If there is an error reading a class file, we now report the version of the classfile and a recommendation to check JDK compatibility:
+
+  ```
+  error while loading String,
+    class file /modules/java.base/java/lang/String.class is broken (version 65.0),
+    please check the JDK compatibility of your Scala version (3.4.0),
+    reading aborted with class java.lang.RuntimeException:
+    foo bar
+  ```
+
+  This will improve the user experience when the class file format changes unexpectedly. This feature will be backported to Scala 3.3.3.
+- 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
+
+### Experimental changes
+
+- 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).
+- `-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.
+
+### Legacy syntax depreacations
+
+Following syntax is now deprecated and will report warnings when used:
+
+- `_` type wildcards (rewrite to `?`)
+- `private[this]` (rewrite to `private`)
+- `var x = _` (rewrite to `var x = scala.compiletime.uninitialized`)
+- `with` as a type operator (rewrite to `&`)
+- `xs: _*` varargs (rewrite to `xs*`)
+- trailing `_` to force eta expansion (can be just ommitted)
+
+All those rewrites will be performed automatically by the compiler if we run it with `-rewrite -source 3.4-migration` flags.
+
+### Other source compatibility concerns
+
+- 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.
+
+  e.g.
+
+  ```scala
+  val xss = List(List(1, 2), List(3))
+
+  for y :: ys <- xss do println(y > 1)
+  //  ^^^^^^^
+  // error: pattern's type ::[Int] is more specialized than the right hand
+  // side expression's type List[Int]
+  //
+  // If the narrowing is intentional, this can be communicated by adding
+  // the `case` keyword before the full pattern, which will result in a filtering
+  // for expression (using `withFilter`).
+  ```
+
+  `.withFilter` is also no longer inserted for a pattern in a generator unless prefixed by `case`, meaning improved ergonomics for many types that do not implement `.withFilter`
+- Type inference has changed for `inline` methods in 3.4, which can cause a source incompatibility at the call site. The previous behaviour can be recovered in an affected file with
+
+  ```scala
+  import scala.language.`3.3`
+  ```
+
+  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)
+
+## Contributors
+
+Thank you to all the contributors who made the release of 3.4.0 and 3.3.2 LTS possible
+
+According to `git shortlog -sn --no-merges 3.3.1..3.4.0` these are:
+
+```
+   474  Martin Odersky
+   296  Nicolas Stucki
+   132  Fengyun Liu
+   119  Dale Wijnand
+    77  Jamie Thompson
+    69  Sébastien Doeraene
+    60  Paweł Marks
+    32  Chris Kipp
+    27  Guillaume Martres
+    26  Rikito Taniguchi
+    21  Yichen Xu
+    19  EnzeXing
+    14  Szymon Rodziewicz
+    13  Lucas Leblanc
+    12  Jakub Ciesluk
+    12  Jędrzej Rochala
+    12  Katarzyna Marek
+    11  Carl
+    10  David Hua
+     9  Florian3k
+     9  Wojciech Mazur
+     8  Eugene Flesselle
+     8  ghostbuster91
+     7  Hamza Remmal
+     7  Jan Chyb
+     7  Ondrej Lhotak
+     7  Quentin Bernet
+     6  Julien Richard-Foy
+     6  Kacper Korban
+     6  Seth Tisue
+     5  Lorenzo Gabriele
+     5  Matt Bovel
+     5  Som Snytt
+     5  Yuito Murase
+     5  dependabot[bot]
+     3  David
+     3  Lucas
+     3  Pascal Weisenburger
+     3  Tomasz Godzik
+     2  Aleksander Rainko
+     2  Decel
+     2  Guillaume Raffin
+     2  Ondřej Lhoták
+     2  Oron Port
+     2  danecek
+     2  rochala
+     1  Adam Dąbrowski
+     1  Aleksey Troitskiy
+     1  Arnout Engelen
+     1  Ausmarton Zarino Fernandes
+     1  Bjorn Regnell
+     1  Daniel Esik
+     1  Eugene Yokota
+     1  Fabián Heredia Montiel
+     1  François Monniot
+     1  Jakub Cieśluk
+     1  John Duffell
+     1  John M. Higgins
+     1  Justin Reardon
+     1  Kai
+     1  Kisaragi
+     1  Lucas Nouguier
+     1  Lukas Rytz
+     1  LydiaSkuse
+     1  Martin Kucera
+     1  Martin Kučera
+     1  Matthew Rooney
+     1  Matthias Kurz
+     1  Mikołaj Fornal
+     1  Nicolas Almerge
+     1  Preveen P
+     1  Shardul Chiplunkar
+     1  Stefan Wachter
+     1  philippus
+     1  q-ata
+     1  slim
+```