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