You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/_posts/2021-07-19-scala-3.0.2RC1-is-here.md
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ title: Scala 3.0.1 and 3.0.2-RC1 are here!
6
6
---
7
7
8
8
Greetings from the Scala 3 team! We are glad to announce that Scala 3.0.1 and 3.0.2-RC1 are now officially out.
9
-
As no critical bugs have been found in the previously released Scala 3.0.1-RC2, it has been promoted to 3.0.1, which is the first stable release after 3.0.0. Scala 3.0.2-RC1, in turn, incorporates new language improvements and bug fixes.
9
+
As no critical bugs have been found in the previously released Scala 3.0.1-RC2, it has been promoted to 3.0.1, which is the first stable release after 3.0.0. Scala 3.0.2-RC1, in turn, incorporates new language improvements and bug fixes. You can expect the release of stable 3.0.2 and a release candidate for a the next version in 6 weeks from now (1st August).
10
10
11
11
# Improved insertion of semicolons in logical conditions
12
12
@@ -27,7 +27,7 @@ if foo(bar)
27
27
then//...
28
28
```
29
29
30
-
If yor intention is to have a block of code evaluating into a sigle condition you should add a new line and indentation directly after `if` , e.g.
30
+
If your intention is to have a block of code evaluating into a single condition you should add a new line and indentation directly after `if` , e.g.
31
31
32
32
```scala
33
33
if
@@ -46,7 +46,7 @@ then //...
46
46
47
47
# Towards better null safety in the type system
48
48
49
-
The compiler option `-Yexplicit-nulls` modifies Scala's standard type hierarchy to allow easier tracing of nullable values by performing strict checks directly on the level of the type system rather than just relying of conventions (e.g. this prevents you from writing code like `val foo: Option[String] = Some(null)`, which would be otherwise valid Scala although very likely to cause a `NullPointerException` at some further point).
49
+
The compiler option `-Yexplicit-nulls` modifies Scala's standard type hierarchy to allow easier tracing of nullable values by performing strict checks directly on the level of the type system rather than just relying on conventions (e.g. this prevents you from writing code like `val foo: Option[String] = Some(null)`, which would be otherwise valid Scala although very likely to cause a `NullPointerException` at some further point).
50
50
51
51
After the recently introduced changes with this option enabled the `Null` type becomes a subtype of `Matchable` instead of inheriting directly from `Any`, making the code below compile (this used to compile before only without strict nullability checking).
52
52
@@ -56,9 +56,9 @@ def foo[T <: Matchable](t: T) = t match { case null => () }
56
56
57
57
# Method search by type signature
58
58
59
-
You can now browse the documentation of Scala's API not only by names of methods but also by their type in a Hoogle-like manner thanks to integration with [Inkuire](https://github.com/VirtusLab/Inkuire) brought up by [#12375](https://github.com/lampepfl/dotty/pull/12375).
59
+
You can now browse the documentation of Scala's API not only by names of methods but also by their type in a [Hoogle](https://hoogle.haskell.org)-like manner (but with Scala syntax) thanks to integration with [Inkuire](https://github.com/VirtusLab/Inkuire) brought up by [#12375](https://github.com/lampepfl/dotty/pull/12375).
60
60
61
-
To find a method with a specified signature simply write in scaladoc's searchbar the type you would expect it to have after eta-expansion (as if this was a function rather than a method).
61
+
To find methods with the desired signature simply write in scaladoc's searchbar the type you would expect them to have after eta-expansion (as if they were functions rather than methods).
This code won't compile. This is because when `Sink[String]` gets erased to `Sink[Object]` (as it's seen from from JVM's perspective) the method's signature becomes `put(x: Object): Unit` while for the structural type it remains unchanged as `put(x: String): Unit` and they wouldn't match in runtime therefore `Sink[String]` cannot be treated as a subtype of `{ def put(x: String): Unit }`.
75
+
This code won't compile. This is because when `Sink[String]` gets erased to `Sink[Object]` (as it's seen from JVM's perspective) the method's signature becomes `put(x: Object): Unit` while for the structural type it remains unchanged as `put(x: String): Unit` and they wouldn't match in runtime therefore `Sink[String]` cannot be treated as a subtype of `{ def put(x: String): Unit }`.
76
76
77
77
We might however try to write a better method dispatch algorithm ourselves instead of relying on the JVM's default one to make this work. To assure the compiler that we know what we're doing we'll need to use the new `Selectable.WithoutPreciseParameterTypes` marker trait. Currently it's an experimental feature (introduced by [#12268](https://github.com/lampepfl/dotty/pull/12268)) so you'll be able to use it only with a snapshot or nightly version of the compiler and you'll need to annotate all subtypes of this trait with `@experimental`.
78
78
@@ -96,7 +96,7 @@ This snippet will compile as the compiler won't perform the precise signature ch
96
96
97
97
# Metaprogramming
98
98
99
-
Keeping in mind how important metaprogramming has become to Scala developers (especially creators of libraries) we continue to make it more reliable by fixing reported bugs and more powerful by repealing formerly introduced limitations. If you're curious how it was done investigate into the PRs below:
99
+
Keeping in mind how important metaprogramming has become to Scala developers (especially creators of libraries) we continue to make it more reliable by fixing reported bugs and more powerful by repealing formerly introduced limitations. If you're curious how it was done look at the PRs below:
100
100
101
101
- Map opaque types in arguments of inlined calls to proxies [#12922](https://github.com/lampepfl/dotty/pull/12922)
102
102
- Don't forget side effects in prefixes of inlined function calls [#12842](https://github.com/lampepfl/dotty/pull/12842)
0 commit comments