Skip to content

Commit e38f90d

Browse files
committed
Add blogpost for releases 3.0.1 and 3.0.2-RC1 - reworks
1 parent 03903b8 commit e38f90d

File tree

1 file changed

+10
-7
lines changed

1 file changed

+10
-7
lines changed

blog/_posts/2021-07-19-scala-3.0.2RC1-is-here.md renamed to blog/_posts/2021-07-21-scala-3.0.2RC1-is-here.md

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,10 @@ title: Scala 3.0.1 and 3.0.2-RC1 are here!
66
---
77

88
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+
10+
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).
11+
12+
Keep on reading to find out what's new in 3.0.2-RC1.
1013

1114
# Improved insertion of semicolons in logical conditions
1215

@@ -27,7 +30,7 @@ if foo(bar)
2730
then //...
2831
```
2932

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.
33+
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.
3134

3235
```scala
3336
if
@@ -46,7 +49,7 @@ then //...
4649

4750
# Towards better null safety in the type system
4851

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).
52+
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).
5053

5154
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).
5255

@@ -56,9 +59,9 @@ def foo[T <: Matchable](t: T) = t match { case null => () }
5659

5760
# Method search by type signature
5861

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).
62+
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).
6063

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).
64+
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).
6265

6366
![image url "image Title"](https://user-images.githubusercontent.com/39772805/117478350-53f12a80-af5f-11eb-82ab-930ba565dacb.gif)
6467

@@ -72,7 +75,7 @@ val a = Sink[String]()
7275
val b: { def put(x: String): Unit } = a
7376
```
7477

75-
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 }`.
78+
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 }`.
7679

7780
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`.
7881

@@ -96,7 +99,7 @@ This snippet will compile as the compiler won't perform the precise signature ch
9699

97100
# Metaprogramming
98101

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:
102+
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:
100103

101104
- Map opaque types in arguments of inlined calls to proxies [#12922](https://github.com/lampepfl/dotty/pull/12922)
102105
- Don't forget side effects in prefixes of inlined function calls [#12842](https://github.com/lampepfl/dotty/pull/12842)

0 commit comments

Comments
 (0)