Add 3.3.0 announcement

blog/_posts/2023-05-26-scala-3.3.0-released.md

@@ -0,0 +1,159 @@
+---
+layout: blog-detail
+post-type: blog
+by: Paweł Marks, VirtusLab
+title: Scala 3.3.0 released!
+---
+
+![Scala 3.3]({{ site.baseurl }}/resources/img/scala-3.3-launch.png)
+
+We are thrilled to announce that after long months of work and careful testing, we have released Scala 3.3.0, the first release in the new 3.3.x LTS series.
+
+## What does "LTS" mean?
+
+Scala 3.3.x is the first Long Term Support (LTS) release series. That means that it will be actively maintained for a period of at least three years. We have adopted a release model similar to the one that Java has successfully used for a long time.
+
+In the following years, there will be new minor releases (3.4, 3.5, and so on) that can bring new backward-compatible features. We are calling them Scala Next; they are equivalent to Java's feature releases. Bug fixes and usability improvements from those releases will be back-ported and released as 3.3.x patches. Apart from those forward and backward-compatible changes, LTS will be feature frozen.
+
+The LTS model doesn't change anything in our compatibility guarantees. Projects built with all future releases will be able to depend on any library compiled with Scala 3.3.x. This is just our standard guarantee that the newer compiler can always consume the output of the older version.
+
+LTS might be a great choice for library authors who can now receive constant bug fixes and developer experience improvements without forcing the users of the library to update the compiler version in their project.
+
+You can read more about our compatibility guarantees in [the recent blog post](https://virtuslab.com/blog/the-scala-3-compatibility-story/).
+
+## What's new in Scala 3.3.0
+
+### Linting
+
+Scala 3.3.0 brings back linting to the Scala compiler.  Right now, you can enable checking for unused symbols and discarded values. More linting options will come soon in the following Scala 3.3.x releases.
+
+#### Checking for unused values
+
+There is an entire family of compiler options added in 3.3.0 for checking and reporting different kinds of unused symbols:
+
+- `-Wunused:imports` - for unused imports
+- `-Wunused:privates` - for unused local definitions
+- `-Wunused:locals`  - for unused local definitions
+- `-Wunused:explicits` - for unused explicit parameters
+- `-Wunused:implicits` - for unused implicit parameters (parameters in `using` clauses)
+- `-Wunused:params` - for all unused method parameters
+- `-Wunused:all` - for enabling all of the above lints
+
+#### Checking for discarded values
+
+Discarding non-unit values is usually the symptom of subtle mistakes. The compiler can now warn you about all discarded values saving you from bugs resulting from those hard-to-spot mistakes.
+
+In the following simplified example
+
+```Scala
+def failure: Either[String, Nothing] = Left("something broke")
+
+def failedComputation: Either[String, Unit] =
+  Right(()).map(_ => failure)
+```
+
+the programmer, by mistake, used the `map` method instead of `flatMap`. The code still compiles, but due to value discarding, behaves unexpectedly, returning `Right(())` from the `failedComputation` method. If the `-Wvalue-discard` flag is enabled, the compiler will report the warning, saving the user from a potential bug.
+
+### More consistent braceless syntax
+
+Braces around method parameters can now be replaced with a colon. This can lead to cleaner, shorter, and often more readable code in places like configuration DSLs or test case definitions.
+
+```Scala
+def canFail(input: String): Try[List[String]] = Try:
+  someComputation(input).flatMap: res =>
+    val partial = moreComputation(res)
+    andEvenMore(partial)
+
+class TestSuite extends munit.FunSuite:
+  test("the job doesn't fail"):
+    val job = canFail("some data")
+    assert(job.isSuccess)
+```
+
+### `boundary` and `break`
+
+Two new methods were added to the standard library: `boundary` and `break`. They are safer and more expressive replacements for non-local returns, which were deprecated recently.
+
+`break` allows for a type-safe early escape from anywhere inside the block delimited by `boundary` to its end, returning the passed value from the entire block.
+
+```Scala
+import util.boundary, boundary.break
+
+def sumOfRoots(number: List[Double]): Option[Double] = boundary:
+  val roots = numbers.map: n =>
+    println(s" * calculating square root for $n*")
+    if n >= 0 then Math.sqrt(n) else break(None)
+  Some(roots.sum)
+```
+
+When you run the above method, you will notice that it returns `None` when any of the input elements is negative. Moreover, thanks to `boundary`/`break`, you can see from the console output that it stops iterating after encountering the first negative element.
+
+`break` can jump out of the `boundary` in the function deeper on the stack. To make it safe, only functions with a matching `Label` in their using clauses can break. This can be used to create isolated parts of an application with streamlined error handling.
+
+Library authors can abstract over `break` and `Label`, creating a nice API for error handling or dealing with uncertain data. We can define the following micro-library as a simplified example:
+
+```Scala
+import util.boundary, boundary.{ Label, break }
+
+type Uncertain[T] = Label[Left[String, Nothing]] ?=> T
+
+def fail(error: String): Uncertain[Nothing] = break(Left(error))
+```
+
+Then it can be used in the following way to create a fragment of a larger application with isolated error handling:
+
+```Scala
+def getUser(id: String): Uncertain[User] =
+  val user = findUser(id)
+  if verifyUser(user) then user else fail("Incorrect user")
+
+def getAddress(user: User): Uncertain[Address] =
+  findAddress(user) match
+    case Some(address) if verifyAddress(address) => address
+    case Some(_) => fail("Incorrect address")
+    case None => fail("Missing address")
+
+def getShippingData(id: String): Either[String, (User, Address)] =
+  boundary:
+    val user = getUser(id)
+    val address = getAddress(user)
+    Right((user, address))
+```
+
+### The new default implementation of lazy vals
+
+Last but not least, we have changed the default implementation of lazy vals. The new implementation has better performance and is safer under parallel access. This may result in improvements in the performance of effect systems.
+
+## Should I update to Scala 3.3.0?
+
+If you are maintaining a standalone Scala 3 project without external projects depending on it, feel free to switch to Scala 3.3.0 at any moment. You will enjoy all the improvements in the newest version of the compiler.
+
+If you are a library author following semantic versioning, we advise you to update to Scala 3.3.0 in the next minor release of your project. Users of your library would also need to bump their compiler version to use the newest version of your library. If you have already published a minor version on 3.3.0 but learned about a critical vulnerability in your library, you should release a new patch release for the previous minor version of your library using Scala 3.2.2 (or any other older version of the compiler ). This patch can be consumed by all the users of previous versions of the library, no matter if they have already switched to 3.3.0 or not.
+
+### Known incompatibility: Stability of inline parameters
+
+In Scala, only stable paths can be used as prefix in path-dependent types.
+
+```Scala
+class Outer:
+  type Inner
+
+val a = new Outer
+val aInner: a.Inner = ???     // ok
+
+var b = new Outer
+// val bInner: b.Inner = ???  // error
+
+def c = new Outer
+// val cInner: c.Inner = ???  // error
+
+def method(param: Outer): param.Inner = ???  // ok
+```
+
+There was a bug that resulted in the compiler assuming that all inline parameters are stable references. This could have led to unsound code being accepted by the compiler and potential runtime crashes.
+
+```Scala
+inline def method(inline param: Outer): param.Inner // error in Scala 3.3.0
+```
+
+Such pieces of code are now rejected by the compiler. The migration for that change is simple, as it only requires removing the `inline` modifier **from the parameter**. If the path-dependent type was used, it is safe to say that the intended behavior was to inline the method without inlining the parameter.