Add blogpost for releases 3.0.1 and 3.0.2-RC1 - reworks

Author: prolativ

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

@@ -6,7 +6,12 @@ title: Scala 3.0.1 and 3.0.2-RC1 are here!
 ---
 
 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.
-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.
+
+As no critical bugs have been found in the previously released Scala 3.0.1-RC2, it has been promoted to 3.0.1. It is the first stable release after 3.0.0 and it incorporates the changes described in detail in the articles for its pre-releases: [3.0.1-RC1](https://dotty.epfl.ch/blog/2021/06/07/scala3.0.1-rc1-release.html) and [3.0.1-RC2](https://dotty.epfl.ch/blog/2021/06/25/scala301-rc2.html). The unified changelog can be found [here](https://github.com/lampepfl/dotty/releases/tag/3.0.1).
+
+Scala 3.0.2-RC1, in turn, incorporates new language improvements and bug fixes described below.
+
+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).
 
 # Improved insertion of semicolons in logical conditions
 
@@ -27,7 +32,7 @@ if foo(bar)
 then //...
 ```
 
-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.
+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.
 
 ```scala
 if
@@ -46,7 +51,7 @@ then //...
 
 # Towards better null safety in the type system
 
-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).
+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).
 
 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).
 
@@ -56,9 +61,9 @@ def foo[T <: Matchable](t: T) = t match { case null => () }
 
 # Method search by type signature
 
-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).
+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).
 
-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).
+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).
 
 ![image url "image Title"](https://user-images.githubusercontent.com/39772805/117478350-53f12a80-af5f-11eb-82ab-930ba565dacb.gif)
 
@@ -72,7 +77,7 @@ val a = Sink[String]()
 val b: { def put(x: String): Unit } = a
 ```
 
-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 }`.
+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 }`.
 
 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`.
 
@@ -96,7 +101,7 @@ This snippet will compile as the compiler won't perform the precise signature ch
 
 # Metaprogramming
 
-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:
+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:
 
 - Map opaque types in arguments of inlined calls to proxies [#12922](https://github.com/lampepfl/dotty/pull/12922)
 - Don't forget side effects in prefixes of inlined function calls [#12842](https://github.com/lampepfl/dotty/pull/12842)