Scala 2 Roadmap Update: the Road to Scala 3

We just published a blog post with an update about the roadmap towards Scala 3.
We’re happy to discuss and answer questions on this thread.

Happy holidays everyone!


I have to say, I think this is a great move. I think it would be good to get on to the new compiler as soon as possible. Macros are the big hurdle, as they can’t be ported, but as far as I can make out most of the debates about changes to Scala are really independent of the Scala2 Dotty transition.

1 Like

The best way to smooth macro transitions is if someone were to implement dotty-style macros in scala 2. It’s technically feasible IIUC but probably a lot of work.

That said, since one version of something can be cross-published to scala 2.13 and 3 with some sources being different, it might be worth just letting everyone have two versions of all their macros.

Although, there are some macros that can’t be implemented in Dotty at all IIUC, namely those that generate members. Travis Brown has taken the approach of using a Scalafix rewrite to generate the members in the source code, kind of how I seem to recall the Eclipse GUI designer working, complete with comments warning not to edit the generated region of code. It’s really unfortunate IMO that Dotty won’t have a better option than that.

Some really important such macros are in Simulacrum, Circe, and Monocle.


What will happen to effect systems wrt the Scala 3 roadmap? Is there a description somewhere of the current status of that?

Happy holidays!

1 Like

That’s true, and I’m keen to see what can be done to address the Circe/Monocle and Simulacrum use cases.

On the positive side, the fact that “whitebox macros” (but with a different name, I think) are now possible in Dotty is great.

Effect systems are still in research stage. They won’t be included in Scala 3.


Will the dotty github migrate to scala/scala as Scala 3? Will the compiler be called dotc or scalac?
Is the “dotty” project done or will it be continued as an experimental forked platform?

1 Like

The plan is to migrate the dotty github to scala/scala, sometimes next year. The compiler command will be called scalac. dotc will remain as the package name of the compiler sources, similar to the role of nsc for Scala 2.

We have not decided yet, but I believe it would be a good idea to keep the dotty project going as an experimental platform for investigating the next big steps for Scala.


The one thing that bothers me with Scala 3 migration plan is that currently, until the all features are approved by the SIP committee, everything is considered experimental. Why would anyone migrate their/others’ code when they are not yet sure that more breaking changes will happen? And also currently we define stuff as “experimental” because we want people to actually experiment. So it becomes a chicken and egg issue. People are afraid to migrate because the features are experimental, and features can’t be finalized until enough people experiment with them.
When do all the Scala 3 SIPs are expected to reach accepted/rejected status with respect to a Scala 3 release candidate?


Does this mean Scala 3.* or Scala 3.0?

Does this mean Scala 3.* or Scala 3.0 ?

Too early to tell. I am pretty sure they won’t be in Scala or the next 3-4 years. What happens afterwards depends on whether they could be added in a backwards compatible way to Scala, in which case they would appear in a Scala 3.x, or whether they require a major version jump. Always assuming that they will eventually arrive, which is not a certainty either. That’s the nature of research.

What do you still like to see in Scala 3?

1 Like

So Scala2.14 is now Scala3.0 and Dotty is Scala3.1 :wink:

I wouldn’t see it so drastic, a lot of experimentation has been and is being done. From the top of my head plus a google search:

It’s not yet the moment to “migrate” to Scala 3, but there are ways to experiment: cross-build, or rewrite a core of some library in Dotty with the goal to test relevant features. Both are really helpful.

The SIP committee just re-instantiated the process of picking a champion (from the committee) for every feature, who will then summarize the proposal and past discussions, and put it to a thread on this forum. The committee will then decide on these features. It will take a few months to go through this process. There was a round of such threads around a year ago, see the “Language Design - SIP Proposal” sub-category.


Not quite. More like Scala 3.0 will include the intent of 2.14: helping the ecosystem transition from Scala 2 to Scala 3. As the blog post says:

To achieve forwards compatibility, the Scala 3 compiler will provide a mechanism to ensure that the public interface is in the common language subset, so that it can be consumed from Scala 2.13. This means that, as a library author, you can adopt (some of) Scala 3 without requiring your users to upgrade from Scala 2.13.


I don’t see anything in the post about Scala runtime reflection, a feature we consider mission-critical to our work. Not every situation can be covered by compile-time macros. I thought I read somewhere that there was work on a new Type class in Dotty to replace TypeTag. Is this correct? Would it allow me to discern important runtime details of an object (fields/members, methods, type parameters, etc.)? For example someone might reflect on a given object that’s typed as a trait. I can presumably get the trait details from a compile-time macro, but I need runtime reflection to get all good stuff on the concrete class that implements the trait at runtime.

I’m good with replacing scala.reflect if there’s something better but frankly it’s good 'nuf as-is for our needs.
Outright killing it w/o a similar replacement is a no-fly/no-migrate for us.

1 Like

Runtime details like class, members, methods, and to some extent type parameters are already covered by Java’s reflection. What do you want to achieve that the java reflection cannot do?

1 Like

Quite a bit, actually. I want/need access to all the Scala details. One example: details on trait implementations (type parameters, etc.) We’re doing full runtime object serialization/deserialization (ScalaJack project). Today I go swimming the deep blue sea of TypeTag.

I hate to throw code blindly at people, but this one file captures most of what we need to do at runtime. Most of it is all about picking apart a Scala class at runtime to see what’s inside. The only major other thing not in this file is type comparison (tpe1 =:= tpe2).

1 Like

Does tasty inspect offer some of what you want?


Not every situation can be covered by compile-time macros. I thought I read somewhere that there was work on a new Type class in Dotty to replace TypeTag.

One example: details on trait implementations (type parameters, etc.) We’re doing full runtime object serialization/deserialization

While this might be considered somehow impure, this is an important topic in a world increasingly based on microservices. How would you bridge between rich and deeply typed Scala islands, when all you can use in-between is a text (or binary) representation of some basic types like in JSON?