|
| 1 | +--- |
| 2 | +layout: blog-page |
| 3 | +title: Announcing Dotty 0.14.0-RC1 with export, immutable arrays, creator applications and more |
| 4 | +author: Anatolii Kmetiuk |
| 5 | +authorImg: /images/anatolii.png |
| 6 | +date: 2019-04-15 |
| 7 | +--- |
| 8 | + |
| 9 | +Hello! This is the 14th release of Dotty. Some of the most interesting changes in this release include the new `export`, the dual of `import`, feature, an immutable array type and the creator applications syntax. |
| 10 | + |
| 11 | +This release serves as a technology preview that demonstrates new |
| 12 | +language features and the compiler supporting them. |
| 13 | + |
| 14 | +Dotty is the project name for technologies that are being considered for |
| 15 | +inclusion in Scala 3. Scala has pioneered the fusion of object-oriented and |
| 16 | +functional programming in a typed setting. Scala 3 will be a big step towards |
| 17 | +realising the full potential of these ideas. Its main objectives are to |
| 18 | + |
| 19 | +- become more opinionated by promoting programming idioms we found to work well, |
| 20 | +- simplify where possible, |
| 21 | +- eliminate inconsistencies and surprising behaviours, |
| 22 | +- build on strong foundations to ensure the design hangs together well, |
| 23 | +- consolidate language constructs to improve the language’s consistency, safety, ergonomics, and |
| 24 | + performance. |
| 25 | + |
| 26 | +You can learn more about Dotty on our [website](https://dotty.epfl.ch). |
| 27 | + |
| 28 | +<!--more--> |
| 29 | + |
| 30 | +This is our 14th scheduled release according to our |
| 31 | +[6-week release schedule](https://dotty.epfl.ch/docs/usage/version-numbers.html). |
| 32 | + |
| 33 | +# What’s new in the 0.14.0-RC1 technology preview? |
| 34 | + |
| 35 | +## Export as a dual of Import |
| 36 | + |
| 37 | +A new `export` keyword is added to the language that defines aliases for selected members of an object. Consider the following example: |
| 38 | + |
| 39 | +```scala |
| 40 | +class BitMap |
| 41 | +class InkJet |
| 42 | +class Printer { |
| 43 | + type PrinterType |
| 44 | + def print(bits: BitMap): Unit = ??? |
| 45 | + def status: List[String] = ??? |
| 46 | +} |
| 47 | +class Scanner { |
| 48 | + def scan(): BitMap = ??? |
| 49 | + def status: List[String] = ??? |
| 50 | +} |
| 51 | +class Copier { |
| 52 | + private val printUnit = new Printer { type PrinterType = InkJet } |
| 53 | + private val scanUnit = new Scanner |
| 54 | + export scanUnit.scan |
| 55 | + export printUnit.{status => _, _} |
| 56 | + def status: List[String] = printUnit.status ++ scanUnit.status |
| 57 | +} |
| 58 | +``` |
| 59 | + |
| 60 | +When defined like this, the `Copier` class defines aliases of the `scanner`'s `scan` method and all the methods of `printUnit` except the `status` method. You can hence call them on the `Copier` as follows: |
| 61 | + |
| 62 | +```scala |
| 63 | +val copier = new Copier |
| 64 | +copier.print(copier.scan()) |
| 65 | +``` |
| 66 | + |
| 67 | +The motivation for this change is to promote composition over inheritance. In OOP languages it is easy to define inheritance but the above example would be tricky if you follow the composition route. One would need to implement proxy methods in the `Copier` to delegate to those of the `Scanner` and the `Printer`. |
| 68 | + |
| 69 | +With the `export` feature, making the `Copier` behave as the `Printer` and the `Scanner` became much more ergonomic. Also, note the fine-grained control over which methods are exposed in cases of the possible method collision, as shown with the `status` method example. |
| 70 | + |
| 71 | +For more information, please read more in the [documentation](http://dotty.epfl.ch/docs/reference/other-new-features/export.html). |
| 72 | + |
| 73 | + |
| 74 | +## An immutable array type |
| 75 | +A new type, `scala.IArray[T]`, is added, which is an immutable version of the `Array` type. Its implementation deserves a special attention, as it uses the new Dotty features in an elegant way (the below is an abstract from the corresponding [commit](https://github.com/lampepfl/dotty/commit/af2a0e66eb4b1204eac5dcb1d979486b92ef93d7#diff-156dc405d9f228bbc0fe406dfba63f65): |
| 76 | + |
| 77 | +```scala |
| 78 | +opaque type IArray[T] = Array[T] |
| 79 | + |
| 80 | +object IArray { |
| 81 | + |
| 82 | + implied arrayOps { |
| 83 | + inline def (arr: IArray[T]) apply[T] (n: Int): T = (arr: Array[T]).apply(n) |
| 84 | + inline def (arr: IArray[T]) length[T] : Int = (arr: Array[T]).length |
| 85 | + } |
| 86 | + def apply[T: ClassTag](xs: T*): IArray[T] = Array(xs: _*) |
| 87 | + /*...*/ |
| 88 | +} |
| 89 | +``` |
| 90 | + |
| 91 | +Essentially, the above defines a wrapper around the ordinary `Array` which exposes only its `apply` (to get an element by index) and `length` methods: |
| 92 | + |
| 93 | +- `opaque type IArray[T]` defines a type which is known to be an `Array`, but this information is known only in its companion object `IArray`. To the rest of the world, this information is not available. |
| 94 | +- The `implied arrayOps` implied instance defines the extension methods that expose the operations available on the `IArray` type. |
| 95 | +- The extension methods, `apply` and `length`, delegate to these of the `Array` type. These methods are inlined which means the performance footprint is the same as that of the original `Array` methods. |
| 96 | +- Because the methods are `inline` and because the `IArray` type is `opaque`, we need the `(arr: Array[T])` casts. `IArray` is known to be equal to `Array` only inside the `IArray` object and the inlining will cause the extension methods' bodies to appear outside the `IArray` object when these methods are called. |
| 97 | + |
| 98 | +## Creator Applications |
| 99 | +This new language feature is a generalisation of the ability to construct case classes without the `new` keyword: |
| 100 | + |
| 101 | +```scala |
| 102 | +class StringBuilder(s: String) { |
| 103 | + def this() = this("") |
| 104 | +} |
| 105 | +StringBuilder("abc") // same as new StringBuilder("abc") |
| 106 | +StringBuilder() // same as new StringBuilder() |
| 107 | +``` |
| 108 | + |
| 109 | +The motivation for the feature is mainly ergonomic. To make it possible, a new interpretation was added to a function call `f(a)`. Previously, the rules were as follows: |
| 110 | + |
| 111 | +Given a function call `f(args)`, |
| 112 | + |
| 113 | + - if `f` is a method applicable to `args`, typecheck `f(args)` unchanged, |
| 114 | + - otherwise, if `f` has an `apply` method applicable to `args` as a member, continue with `f.apply(args)`, |
| 115 | + - otherwise, if `f` is of the form `p.m` and there is an implicit conversion `c` applicable to `p` so that `c(p).m` is applicable to `args`, continue with `c(p).m(args)` |
| 116 | + |
| 117 | + There's now a fourth rule following these rules: |
| 118 | + |
| 119 | + - otherwise, if `f` is syntactically a stable identifier, and `new f` where `f` is interpreted as a type identifier is applicable to `args`, continue with `new f(args)`. |
| 120 | + |
| 121 | +For more information, please see the [documentation](http://dotty.epfl.ch/docs/reference/other-new-features/creator-applications.html). |
| 122 | + |
| 123 | +## Other changes |
| 124 | + |
| 125 | +Some of the other changes include: |
| 126 | + |
| 127 | +- `infer` method renamed to `the`, the semantics of which is now the same as that of the `the` method of Shapeless. Namely, the implicits are resolved more precisely – see this [gist](https://gist.github.com/milessabin/8833a1dbf7e8245b30f8) for an example in Shapeless, and the Dotty [documentation](http://dotty.epfl.ch/docs/reference/contextual/inferable-params.html#querying-implied-instances) for more details. |
| 128 | +- The syntax of quoting and splicing was changed. Now the quoting is expressed via `'{ ... }` and `'[...]` and splicing – via `${...}` and `$id`. Please see the [documentation](http://dotty.epfl.ch/docs/reference/other-new-features/principled-meta-programming.html) for more details on these features. |
| 129 | + |
| 130 | +# Let us know what you think! |
| 131 | + |
| 132 | +If you have questions or any sort of feedback, feel free to send us a message on our |
| 133 | +[Gitter channel](https://gitter.im/lampepfl/dotty). If you encounter a bug, please |
| 134 | +[open an issue on GitHub](https://github.com/lampepfl/dotty/issues/new). |
| 135 | + |
| 136 | +## Contributing |
| 137 | + |
| 138 | +Thank you to all the contributors who made this release possible! |
| 139 | + |
| 140 | +According to `git shortlog -sn --no-merges 0.13.0-RC1..0.14.0-RC1` these are: |
| 141 | + |
| 142 | +``` |
| 143 | + 214 Martin Odersky |
| 144 | + 151 Nicolas Stucki |
| 145 | + 71 Liu Fengyun |
| 146 | + 53 Guillaume Martres |
| 147 | + 26 Olivier Blanvillain |
| 148 | + 10 Aleksander Boruch-Gruszecki |
| 149 | + 9 Aggelos Biboudis |
| 150 | + 6 Miles Sabin |
| 151 | + 4 Allan Renucci |
| 152 | + 4 Dale Wijnand |
| 153 | + 3 Anatolii Kmetiuk |
| 154 | + 2 Fengyun Liu |
| 155 | + 2 Alex Zolotko |
| 156 | + 1 gnp |
| 157 | + 1 tim-zh |
| 158 | + 1 Dmitry Petrashko |
| 159 | + 1 Dotty CI |
| 160 | + 1 Jasper Moeys |
| 161 | + 1 Jentsch |
| 162 | + 1 Jim Van Horn |
| 163 | + 1 Lionel Parreaux |
| 164 | + 1 Master-Killer |
| 165 | + 1 Olivier ROLAND |
| 166 | + 1 Robert Stoll |
| 167 | + 1 Seth Tisue |
| 168 | + 1 Tomasz Godzik |
| 169 | + 1 Victor |
| 170 | +``` |
| 171 | + |
| 172 | +If you want to get your hands dirty and contribute to Dotty, now is a good time to get involved! |
| 173 | +Head to our [Getting Started page for new contributors](https://dotty.epfl.ch/docs/contributing/getting-started.html), |
| 174 | +and have a look at some of the [good first issues](https://github.com/lampepfl/dotty/issues?q=is%3Aissue+is%3Aopen+label%3Aexp%3Anovice). |
| 175 | +They make perfect entry points into hacking on the compiler. |
| 176 | + |
| 177 | +We are looking forward to having you join the team of contributors. |
| 178 | + |
| 179 | +## Library authors: Join our community build |
| 180 | + |
| 181 | +Dotty now has a set of widely-used community libraries that are built against every nightly Dotty |
| 182 | +snapshot. Currently this includes ScalaPB, algebra, scalatest, scopt and squants. |
| 183 | +Join our [community build](https://github.com/lampepfl/dotty-community-build) |
| 184 | +to make sure that our regression suite includes your library. |
| 185 | + |
| 186 | +[Scastie]: https://scastie.scala-lang.org/?target=dotty |
| 187 | + |
| 188 | +[@odersky]: https://github.com/odersky |
| 189 | +[@DarkDimius]: https://github.com/DarkDimius |
| 190 | +[@smarter]: https://github.com/smarter |
| 191 | +[@felixmulder]: https://github.com/felixmulder |
| 192 | +[@nicolasstucki]: https://github.com/nicolasstucki |
| 193 | +[@liufengyun]: https://github.com/liufengyun |
| 194 | +[@OlivierBlanvillain]: https://github.com/OlivierBlanvillain |
| 195 | +[@biboudis]: https://github.com/biboudis |
| 196 | +[@allanrenucci]: https://github.com/allanrenucci |
| 197 | +[@Blaisorblade]: https://github.com/Blaisorblade |
| 198 | +[@Duhemm]: https://github.com/Duhemm |
| 199 | +[@AleksanderBG]: https://github.com/AleksanderBG |
| 200 | +[@milessabin]: https://github.com/milessabin |
0 commit comments