Skip to content

Commit b33eb98

Browse files
committed
Add blogpost for 3.0.1 and 3.0.2-RC1
1 parent 2aa2551 commit b33eb98

File tree

2 files changed

+226
-0
lines changed

2 files changed

+226
-0
lines changed
Lines changed: 226 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,226 @@
1+
---
2+
layout: blog-page
3+
title: Scala 3.0.1 and 3.0.2-RC1 are here!
4+
author: Michał Pałka
5+
authorImg: /images/michal.jpg
6+
date: 2021-07-19
7+
---
8+
9+
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.
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.
11+
12+
<!--more-->
13+
14+
# Improved insertion of semicolons in logical conditions
15+
16+
Scala 3's indentation based syntax is aimed at making your code more concise and readable. As it gets broader adoption, we consistently improve its specification to eliminate corner cases which might lead to ambiguities or counterintuitive behaviours.
17+
18+
Thanks to [#12801](https://github.com/lampepfl/dotty/pull/12801) it is now allowed for a logical expression in an `if` statement or expression to continue in the following line if it starts in the same line as the `if` keyword, e.g.
19+
20+
```scala
21+
if foo
22+
(bar)
23+
then //...
24+
```
25+
26+
can now be used instead of
27+
28+
```scala
29+
if foo(bar)
30+
then //...
31+
```
32+
33+
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.
34+
35+
```scala
36+
if
37+
val cond = foo(bar)
38+
cond
39+
then //...
40+
```
41+
42+
so code like below would NOT be valid
43+
44+
```scala
45+
if val cond = foo(bar)
46+
cond
47+
then //...
48+
```
49+
50+
# Towards better null safety in the type system
51+
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 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).
53+
54+
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).
55+
56+
```scala
57+
def foo[T <: Matchable](t: T) = t match { case null => () }
58+
```
59+
60+
# Method search by type signature
61+
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-like manner thanks to integration with [Inkuire](https://github.com/VirtusLab/Inkuire) brought up by [#12375](https://github.com/lampepfl/dotty/pull/12375).
63+
64+
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).
65+
66+
![image url "image Title"](https://user-images.githubusercontent.com/39772805/117478350-53f12a80-af5f-11eb-82ab-930ba565dacb.gif)
67+
68+
# Typing escape hatch for structural types
69+
70+
Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn't normally play well with method overloading because some types of reflective dispatch algorithms (inlcuding JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
71+
72+
```scala
73+
class Sink[A] { def put(x: A): Unit = {} }
74+
val a = Sink[String]()
75+
val b: { def put(x: String): Unit } = a
76+
```
77+
78+
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 }`.
79+
80+
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`.
81+
82+
```scala
83+
import annotation.experimental
84+
85+
@experimental trait MultiMethodSelectable extends Selectable.WithoutPreciseParameterTypes:
86+
// smartly choose the right method implementation to call
87+
def applyDynamic(name: String, paramTypes: Class[_]*)(args: Any*): Any = ???
88+
89+
@experimental class Sink[A] extends MultiMethodSelectable:
90+
def put(x: A): Unit = {}
91+
92+
val a = new Sink[String]
93+
val b: MultiMethodSelectable { def put(x: String): Unit } = a
94+
```
95+
96+
This snippet will compile as the compiler won't perform the precise signature check for `b` anymore.
97+
98+
[More details](https://dotty.epfl.ch/docs/reference/changed-features/structural-types-spec.html#limitations-of-structural-types)
99+
100+
# Metaprogramming
101+
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 investigate into the PRs below:
103+
104+
- Map opaque types in arguments of inlined calls to proxies [#12922](https://github.com/lampepfl/dotty/pull/12922)
105+
- Don't forget side effects in prefixes of inlined function calls [#12842](https://github.com/lampepfl/dotty/pull/12842)
106+
- Drop "no inlines with opaques" implementation restriction [#12815](https://github.com/lampepfl/dotty/pull/12815)
107+
- Detect abstract inline method calls after inlining [#12777](https://github.com/lampepfl/dotty/pull/12777)
108+
- Fix implicit ValueOf synthesis [#12615](https://github.com/lampepfl/dotty/pull/12615)
109+
110+
# Other notable improvements
111+
112+
- Fix [#12981](https://github.com/lampepfl/dotty/issues/12981): show diagnostics levels (warn | error) in REPL [#13000](https://github.com/lampepfl/dotty/pull/13000)
113+
- Add no links warning setting to scaladoc [#12936](https://github.com/lampepfl/dotty/pull/12936)
114+
- Use WeakHashSet instead of HashSet for hash-consing types [#12935](https://github.com/lampepfl/dotty/pull/12935)
115+
- Balance And/Or types when forming lubs and glbs [#12928](https://github.com/lampepfl/dotty/pull/12928)
116+
- Restricts isInstanceOf[Null] checks [#12905](https://github.com/lampepfl/dotty/pull/12905)
117+
- Add support for shallow capture sets [#12875](https://github.com/lampepfl/dotty/pull/12875)
118+
- Drop implementation restriction for polymorphic functions [#12863](https://github.com/lampepfl/dotty/pull/12863)
119+
- Preserve hard unions in more situations [#12654](https://github.com/lampepfl/dotty/pull/12654)
120+
- Better support type-heavy pattern matches [#12549](https://github.com/lampepfl/dotty/pull/12549)
121+
122+
# Other notable bug fixes
123+
124+
- Fix [#13046](https://github.com/lampepfl/dotty/issues/13046): override is a valid identifier in Java, not a keyword [#13048](https://github.com/lampepfl/dotty/pull/13048)
125+
- Don't emit Java generic signatures for constructors [#13047](https://github.com/lampepfl/dotty/pull/13047)
126+
- Exhaustivity warnings on nested case classes [#13030](https://github.com/lampepfl/dotty/pull/13030)
127+
- Refine overriding pairs in RefChecks [#12982](https://github.com/lampepfl/dotty/pull/12982)
128+
- Let annotations on parameters see preceding type parameters [#12980](https://github.com/lampepfl/dotty/pull/12980)
129+
- Retain transparent flag on exports [#12978](https://github.com/lampepfl/dotty/pull/12978)
130+
- Widen unions before finding members [#12925](https://github.com/lampepfl/dotty/pull/12925)
131+
- ProtoTypes#normalizedCompatible: keep more constraints [#12924](https://github.com/lampepfl/dotty/pull/12924)
132+
- Detect provisional superclasses and recompute them in Typer [#12912](https://github.com/lampepfl/dotty/pull/12912)
133+
- Properly handle self-types in reflection member lookup [#12893](https://github.com/lampepfl/dotty/pull/12893)
134+
- Use Java rules for member lookup in .java sources [#12884](https://github.com/lampepfl/dotty/pull/12884)
135+
- Hide problematic static forwarders [#12860](https://github.com/lampepfl/dotty/pull/12860)
136+
- When checking tp1 <:< tycon2[args2], widen tp1 to reveal application [#12846](https://github.com/lampepfl/dotty/pull/12846)
137+
- Skip contexts for implicit search when resolving imports [#12816](https://github.com/lampepfl/dotty/pull/12816)
138+
- Insert conversions also on selections wrapped in type applications [#12719](https://github.com/lampepfl/dotty/pull/12719)
139+
- Emit generic signature for static forwarders to nullary methods [#12710](https://github.com/lampepfl/dotty/pull/12710)
140+
- Add Matchable to the parents of Null in explicit nulls [#12697](https://github.com/lampepfl/dotty/pull/12697)
141+
- Always generate a partial function from a lambda [#12670](https://github.com/lampepfl/dotty/pull/12670)
142+
- Fix [#12572](https://github.com/lampepfl/dotty/issues/12572): Ignore default accessor bridges in non-native JS classes. [#12657](https://github.com/lampepfl/dotty/pull/12657)
143+
144+
# Contributors
145+
Thank you to all the contributors who made this release possible 🎉
146+
147+
According to `git shortlog -sn --no-merges 3.0.1-RC2..3.0.2-RC1` these are:
148+
149+
```
150+
85 Martin Odersky
151+
60 Liu Fengyun
152+
47 Kacper Korban
153+
28 Filip Zybała
154+
17 Andrzej Ratajczak
155+
16 Guillaume Martres
156+
15 Jamie Thompson
157+
10 bjornregnell
158+
9 tanishiking
159+
8 Dylan Halperin
160+
8 Anatolii Kmetiuk
161+
7 Tom Grigg
162+
5 Som Snytt
163+
5 changvvb
164+
4 Nicolas Stucki
165+
4 Aleksander Boruch-Gruszecki
166+
4 Sébastien Doeraene
167+
4 Michał Pałka
168+
3 Magnolia.K
169+
3 Phil
170+
3 Krzysztof Romanowski
171+
3 Paweł Marks
172+
2 xuwei-k
173+
2 Ben Plommer
174+
2 Florian Schmaus
175+
2 Lukas Rytz
176+
2 Maciej Gorywoda
177+
2 Markus Sutter
178+
2 Roman Kotelnikov
179+
2 Stéphane Micheloud
180+
2 noti0na1
181+
2 vincenzobaz
182+
1 Ondrej Lhotak
183+
1 KazuyaMiayshita
184+
1 odersky
185+
1 Julian Mendez
186+
1 Anton Sviridov
187+
1 GavinRay97
188+
1 EnzeXing
189+
1 Tomas Mikula
190+
1 Tomasz Godzik
191+
1 Vaastav Arora
192+
1 Vadim Chelyshov
193+
1 Will Sargent
194+
1 Zofia Bartyzel
195+
1 Dale Wijnand
196+
1 Bjorn Regnell
197+
1 dmitrii.naumenko
198+
1 Adrien Piquerez
199+
1 Meriam Lachkar
200+
1 Martin
201+
1 Olivier Blanvillain
202+
1 Lorenzo Gabriele
203+
```
204+
205+
## Library authors: Join our community build
206+
207+
Scala 3 now has a set of widely-used community libraries that are built against every nightly Scala 3 snapshot.
208+
Join our [community build](https://github.com/lampepfl/dotty/tree/master/community-build)
209+
to make sure that our regression suite includes your library.
210+
211+
[Scastie]: https://scastie.scala-lang.org/?target=dotty
212+
213+
[@odersky]: https://github.com/odersky
214+
[@DarkDimius]: https://github.com/DarkDimius
215+
[@smarter]: https://github.com/smarter
216+
[@felixmulder]: https://github.com/felixmulder
217+
[@nicolasstucki]: https://github.com/nicolasstucki
218+
[@liufengyun]: https://github.com/liufengyun
219+
[@OlivierBlanvillain]: https://github.com/OlivierBlanvillain
220+
[@biboudis]: https://github.com/biboudis
221+
[@allanrenucci]: https://github.com/allanrenucci
222+
[@Blaisorblade]: https://github.com/Blaisorblade
223+
[@Duhemm]: https://github.com/Duhemm
224+
[@AleksanderBG]: https://github.com/AleksanderBG
225+
[@milessabin]: https://github.com/milessabin
226+
[@anatoliykmetyuk]: https://github.com/anatoliykmetyuk

docs/images/michal.jpg

843 KB
Loading

0 commit comments

Comments
 (0)