First batch of Scala 3 SIPs

Hello everyone,

In the last Scaladays conferences, @odersky and @adriaanm talked about the future of the language, Scala 3, in their keynote. In the talk, Martin and Adriaan address how will the migration look like, but many people have asked us (Scala Center/EPFL/Lightbend) how we are going to handle this transition at the language level:

  1. “There have been lots of changes in Scala 3, are they going to be reviewed by the SIP Committee?”
  2. “How are they going to be reviewed?”

These are all important questions and in this thread I’d like to motivate our approach.

Every change that has gone into Scala 3 (the Dotty compiler), be it an addition, improvement or removal, will be reviewed by the SIP Committee, just as any change that modifies the Scala language specification.

There are a quite a few changes in Scala 3, and so we need to find a good strategy to review them all on time before the feature freeze in Scala 3 and its official 3.0.0 release. In our two previous SIP meetings (June 2018 and May 2018), the Committee agreed on a review strategy: we would group them in several batches by their semantics and then review them slowly in every meeting. At the end of the review process, we would have a decision on which language features of the batch will make it to the Scala 3 release and move to the next batch until all of them have been reviewed.

Some of the high-level particulars that will be discussed are “What would be the subset of Scala represented in Tasty trees” or “Which changes will make it for Scala 2.14” as these questions are fundamental to our review process. In Adriaan’s talk “State of the Scala 2 Union” and the last SIP meetings there are already some partial answers to these questions.

However, we cannot do this alone. As usual for SIPs, we would like to get the comments from you, the community. Since those changes have the potential to significantly impact the Scala language, we are making an extra effort this time to reach out for feedback.

There have been some chats on what is the most efficient way of listening to your feedback. In one of our meetings, @heathermiller proposed to follow the “Why Wasn’t I Consulted” strategy (popularized by the Rust programming language community). This strategy works as follows: we set a timeframe (in our case, a month) in which we will accept and act on any technical feedback (be it a question, remark or suggestion). This feedback will then be taken into consideration when making decisions in our SIP meetings and some of the Committee members will answer your feedback online.

This first batch that we have prepared and already discussed in our meeting in June is the so-called “syntactic batch”, which mostly considers the syntactic changes that have gone into Scala 3. The batch is available at the end of this article.

I’m hoping to see a lot of activity in these batches, and I’m personally very excited about what we can do together to make Scala 3 a turning point in the lifetime of the Scala language.

The proposals in this batch are:

  1. DelayedInit or OnCreate, any solution? - #10 by MichaelJAllen (I didn’t create a new thread for delayed init as there was already an active one. All feedback should go here.)
  2. Proposal to remove procedure syntax
  3. Proposal to remove auto application from the language
  4. Proposal to remove XML literals from the language
  5. Proposal to remove early initializers from the language - #3 by jvican

Have a good day,


I just want to mentione that IntelliJ has been fixing procedure syntax for a long time, which is why I don’t have it in my code-base. Even before official deprecation and removal, it is good if the tools clearly mark/fix used features that are on their way out. Scalafix is a good solution for users to apply themselves, but if the IDEs incorporate these abilities out-of-the-box, it would greatly improve migration.