Add 3.4.0 blogpost

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

@@ -0,0 +1,187 @@
+---
+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 awaited versions of Scala: the first one in the 3.4 minor line and the patch for the Long Term Support line.
+
+## ... so which version should I update to?
+
+Scala 3.4.0 and 3.3.2 share most of the changes compared to the 3.3.1 version. The difference is that while there are new features and deprecations of legacy mechanisms in Scala 3.4.0, version 3.3.2 is focused solely on bug fixes and usability improvements. What's more, it maintains not only full output compatibility but also full source compatibility. **This means that every single one from over a thousand projects that we have checked that worked correctly with 3.3.1 is also working now with 3.3.2.** This required us to be extra careful with picking changes for that release. Because of that, not every bug that is fixed in 3.4.0 is also fixed in 3.3.2. Some of the not-ported changes only require some additional work, so you may expect them in 3.3.3.
+
+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.
+
+## What's new in 3.3.2 LTS and 3.4.0
+
+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 right now confident in the state of coverage.
+
+The other important, but invisible at first, change is integration of the presentation compiler into the compiler itself. This simplifies the lives of tooling developers and allows for a more stable and reliable user experience when using Metals.
+
+## Changes exclusive to 3.4.0
+
+- 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
+  ```
+
+- Polymorphic lambdas are now implemented using JVM lambdas when possible instead of anonymous classes, which will make them more efficient.
+- 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)
+- [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.
+- 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.
+- `-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.
+- 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.
+- 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.
+- In 3.4, 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 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)
+- JVM Backend parallelization has been ported from Scala 2.13 to Scala 3.
+- The compiler now avoids generating given definitions that loop, removing long-standing footman of implicit resolution.
+
+### Road to Pipelined Builds
+
+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.
+
+- 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.
+- 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.
+
+## 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
+
+```