0.15.0-RC1 Blog Post Draft #6544
Conversation
|
I propose to make this the "Full Bootstrap" release which means to mention bootstrap first (#5923). Can you include a small paragraph? |
|
@biboudis I've added more stress on bootstrap – how does it look now? |
|
|
||
| # What’s new in the 0.15.0-RC1 technology preview? | ||
| ## Operator Rules | ||
| This change addresses the problem of the regulation of whether an operator is supposed to be used in an infix position. The motivation is for the library authors to be able to enforce whether a method or a type is supposed to be used in an infix position by the users. This ability will help to make code bases more consistent in the way the calls to methods are performed. |
There was a problem hiding this comment.
This change addresses ... position. -> We introduce two annotations that regulate the use of operators. The first is called @infix and the second is called @alpha. The motivation behind @infix is ...
There was a problem hiding this comment.
Actually only one annotation, @alpha doesn't work yet (although is defined). #5975 says it will come in a separate PR, which I haven't seen yet.
There was a problem hiding this comment.
Good catch. I thought it was in @anatoliykmetyuk. @odersky since @alpha is not yet in I propose to enclose the relevant section in the docs in comments.
| val res2: Int = 3 | ||
| ``` | ||
|
|
||
| As the warning says, if you want the users of the method to be able to use it in an infix position, you can do so as follows: |
There was a problem hiding this comment.
you can do so -> they can do so
There was a problem hiding this comment.
"you", since that's the author of the code that has the control over how the method is used. If it is not marked as infix by the author, there's nothing (probably) "they" can do to get rid of the warning.
| } | ||
| ``` | ||
|
|
||
| We've also plugged a few soundness problems caused by inferring too much when matching on abstract, union and intersection types. |
There was a problem hiding this comment.
Maybe add the PR number (this right #2985)?
There was a problem hiding this comment.
@AleksanderBG is that issue correct here?
There was a problem hiding this comment.
It'd be better placed in the first line, which talks about variant GADTs. We can mention #5667 for an example of the soundness problems as well, though I didn't really create an issue for that.
| This is our 15th scheduled release according to our | ||
| [6-week release schedule](https://dotty.epfl.ch/docs/contributing/release.html). | ||
|
|
||
| # What’s new in the 0.15.0-RC1 technology preview? |
There was a problem hiding this comment.
I would write a small paragraph:
Bootstrapping Dotty is a big milestone for us and in compiler construction in general. Firstly, we feel more confident that our compiler works as is (even without reusing the new features). Secondly, in the immediate future, we will be able to reuse many of the features that dotty proposes within dotty itself. For example, we have no fewer than 2641 occurrences of the text string
(implicit ctx: Context)in the compiler that we can scrap with Contextual Function types. Big milestones have high risk/high gain and we must be attentive. That is the reason that we will wait a bit until we start using new features. Consequently, at the moment we cross-compile the build with 2.12 on the CI so that we don't accidentally start using Dotty features in case we need to revise the bootstrap process (we'll start using Dotty features eventually, but let's wait until we're confident that this setup works well enough).Check the following for more information #5923 (comment) and please let us know if you have any incremental compilation issues or anything else!
Before merging we should not forget to compute the Contributors section, which we'll be able to do when we create the release tag further down the release pipeline.