Preparing for Feature Freeze

Hi Everyone,

As the SIP process lead in the last year, I feel it is my duty to clear our a couple of things.

  1. I take full responsibility for not updating the list(s). I need help, whoever has some time to invest to work with me to put up the missing minutes and make sure all updates are in order, it would mean a lot to me. @dwijnand joined SIP to help with upcoming meetings (big thanks!).

Here are the reasons I haven’t been able to keep up: at first I was only in charge of scheduling and minutes, then I picked up the lead role in SIP and organized Scala Days, and many other responsibilities came up. There are too many moving parts with all new features and events that happen, that it got increasingly harder as one person to keep up with the updates.

  1. If you are interested in the SIP committee role in Scala 3, please check the minutes from May 2019 and November 2018.

In short, the SIP committee is working closely on steering the Scala 3 release - but we do need to create the path as we walk on it.

  1. We should go over the SIPs that are pending.

  2. We agreed that some instances in the process itself, regarding proposing and stages, need to be revised. But we didn’t make final changes and notified the public. This happened 2 days ago, when we had a SIP meeting to discuss many organizational points (how we organize ourselves, who can invest how much time, what makes sense and so forth).

In conclusion, the Dotty team decided to go in the feature freeze soon. This will allow the SIP Committee to know what we are dealing with, no more chasing features. The next public meeting will be the end of November (still waiting on the exact date), another one before Christmas, retreat in February or March.

I hope this helps better understanding of where we stand with SIP and Dotty relations.



  • if you want to know more about or help and support the SIP Committee work, please come chat with me at I will be available as of Monday as of 9 AM CET to answer.

  • I would advise using this thread from here on to stay focused, feature freeze is coming, Martin nicely, timely, and precisely explained context and steps. This thread was proposed as drafting your ideas before the feature freeze.

  • I am personally happy feature freeze is around the corner, we’ve all been waiting for this glorious day (o:


As for the actual proposals, I really like and looked forward to (which is from 2017) and (which is more recent). Others may care about other ones more.

But the feeling that contributions that members of the community who jumped through all the hoops to make a SIP are then being treated as if they should be grateful if the time and effort they spend in making the language better for everyone is difficult to shake. When proposing a SIP makes you feel like a nuisance at best - and currently I feel like I nuisance for putting this on the agenda - then something is not right, and maybe you should just not allow for people who dont work for EPFL or Lightbend to make SIPs.


I totally understand the feeling and am sure not many people would disagree that that is how it comes across. There is a lot that goes in pre and post SIP meeting organization - which I could use help with, that would, in turn, unlock some of the bottle-necks and make this process fluid, thereafter more responsive, or at least stop appearing disrespectful to people’s time. We need to do better, and I can use all the help as I mentioned above.

But rest assured, there is no intention or consciences decision to “lead people on”, and any insinuation to that effect may actually directly hurt my feelings, being the one who is actively trying to navigate this very complex process, with very busy members, in a very particular period of the Scala language history, in the midst of very opinionated crowd. So again, I am finally asking for help, if you are interested in what it entails, ping me at

1 Like

And - I personally want to thank all the members that are following, are interested in, are writing up SIPs, for all that share their ideas on how to improve the Improvement Process - you are already helping me, and I am looking forward to reaching the point of having a great SIP process that everyone is proud of.


This is already implemented in Dotty.

This is on the radar of the SIP committee (notice it was merged only a few days ago)

As some constructive feedback, here are some things that could have been done to make this look much better, even if none of the underlying facts are changed:

  1. Differentiate between Dotty and Scala: if we are freezing the SIP process for the next N weeks/months/years to try and land Scala 3, we should say so up front. This doesn’t just affect Dotty developers, so we should make that clear up front.

  2. Acknowledge that there’s a change in the SIP process, and what it is. Just saying “this is a thing we’re changing, for these reasons” is a big improvement over changing things and leaving it to others to notice that something changed, and trying to figure out which things they were told in the past are no longer true.

  3. Differentiate between the SIP process and Martin: it does not look good at all to have Martin come out and say “we’re changing the rules, and here are the new rules that just so happen to make it much easier for the proposals I’ve been working on to get in, and harder for others”. Even if it’s just someone else making the announcement that the SIP process changed, would look a lot better.

  4. Have a migration plan for people who are invested in the old process: there is a finite/small number of old SIPs, saying “these SIPs are migrated in this way, these SIPs we’ll reject, these SIPs seem inactive and we’ll close for now”. People put in a lot of effort and thought into those proposals, often at Martin’s request: “this will need a SIP” comes up quite often in discussions! These SIPs have been provided: now what?

  5. Anticipate and acknowledge those negatively affected by the change in process. There are O(1000s) who can contribute under the old process (experience writing compiler plugins or patching the Scala compiler), an O(10s) of people under the new process (experience working in lampepfl/dotty). Those 1000s of people are effectively locked out under the new process. I’m one of these people: what about us? Even just a simple note “sorry we’re de-facto locking you out of the SIP process for now, we need to do this in order to land Scala 3 on time” would make me feel a lot better than being casually excluded out of hand.

It’s inevitable that processes need to change and evolve, but we need to treat the process and its evolution with respect ourselves if we want other people to respect it. Having a proper process and having no process at all (i.e. closed development) are both reasonable places to be, but if we’re in an ambiguous state we should decide which direction we want to go so people in the community will know whether the SIP process is a good use of their time and energy.

8 Likes isn’t working for me. What an I missing?

Hi @lihaoyi,

Thank you for the feedback. As I said a couple of times in this thread - if you are willing to help improve the process, ping me at

This thread is strictly for new ideas in the context of feature freeze.

Going forward, everything that is unrelated to the core of Martin’s post will be marked “off topic”, either propose a new thread or use the channel I proposed, or send me an email if you are interested in a) improving the process b) improving the communication, because it is but me who is juggling these things.

But since you made such strong points, I will have to answer:

  • SIP process is still ongoing, there is no freezing the SIP process.
  • Only the Dotty team decided not to add any new features, wants to start preparing for the next phase.
  • SIP process changed last November, acknowledging that what we are dealing with is a different set of changes than usual
    Please read this FAQ about Scala 3 and SIP committee where we address all the points last November.

And I repeat, we are creating a path as we are walking on it. We are aware that things we (the SIP committee) do may seem a certain way. We acknowledge we can do better. I am asking for help. It is getting tiring to fight with the perceptions, if you want to help by giving me ideas or being a part of it in some ways, do tell (Gitter or email).

Splitting a topic is only available to those with moderator tools. Rather than hiding comments as off topic, splitting them off in to a new thread sounds better.

I agree, which is why I proposed a different channel where people can talk directly to me and get instant feedback, and we can do things faster.

If someone wants to open a full thread about the meta issues, feel free.

If even after all the explanations and asking to move to another place/thread people still insist picking on off topic matters, I will mark them as “off topic”. To be clear, getting closer to realising Scala 3 will need a lot of focus, this is where we start:
a) stay on topic
b) if you have an “off topic” question and you get an answer, respect it’s scope
c) if you don’t get an answer, ping a person you think should react
d) make sure your constructive criticism is heard by a person that can actually do something about it (in this case everything SIP committee, agenda, communication related is me)

To be respectful of everyone’s time and intellect, I decided to draw the line here and now.

Hmm looks like I was wrong, we allow type parameters to refer to previous term parameters in the same list, but not default values, so you can write def foo(x: Int, y: List[x.type] = Nil) but not def foo(x: Int, y: List[x.type] = List(x)), I think that’s an oversight / easily fixed, since there’s apparently a SIP for it I’ll bring it up at the next SIP meeting.

1 Like

Is there an agenda for the next SIP meeting yet? Will other SIPs except this one be discussed? If so, which ones, and how was that selection made?

The problem is how to translate this. The current draft SIP does not contain an implementation, nor does it sketch a scheme for it. The feature is clearly desirable, but it looks hard to implement without making default arguments less efficient in general. I guess that’s why the SIP is stuck in draft stage.

Part of that agenda will come from @sjrd’s prioritisation list on Scala 3 features. I expect, much like in the October SIP meeting we just had, we’ll also try and do some of the other, still pending SIPs. But which ones, I’m not sure, and I’m also looking forward to an updated SIP list.

1 Like

(Not sure where to discuss this, is closed).

What do you think would make defaults less efficient, creating the local variables and passing them to default getters?

def substring(s: String, start: Int = 0, end: Int = s.length): String
def substring$default$2(s: String): Int = 0
def substring$default$3(s: String, start: Int): Int = s.length
  val x$1 = someString()
  val x$2 = substring$default$2(x$1)
  val x$3 = substring$default$3(x$1, x$2)
  substring(x$1, x$2, x$3)

The parameters could be avoided if not used, but that would require giving up the feature of inherited defaults. Maybe that feature is questionable anyway, and defaults should always be picked based on the static type? That would require a new naming scheme for default getters though (or make them static). On the negative, it changing a default could eaily break binary compatibility.

One issue with creating locals (also present today when using named args or defaults with dependencies) is that the local variables can extend the lifetime of assigned objects. We had this issue with inlined local varialbes, but they are nulled out now.

Yes, exactly.

Could the getters be inline so that this penalty disappears?

I think that would be too annoying, since you’d be required to write default arguments in every implementation of a method. On the other hand, we might make default getters final. I.e. once a default argument is defined, it cannot be overridden. That would free us from having to use a fixed naming scheme’

1 Like

I do not think the traditional SIP process of proposing features independently, prototyping them in isolation, and then independently voting on them works as well for Scala 3 as it did for Scala 2.x (and it’s not how, e.g., Kotlin was developed).

Scala 3 is the next major iteration of the language and requires architectural work to identify and exploit connections between disparate features and produce a unified vision of all language improvements, built on a long history of experience with the language.

Indeed, some language improvements might not make sense in isolation to existing Scala users (especially if they have a learning cost, which will make them more “controversial” to those with a significant investment in the language), but when taken together, they provide a compelling and unified vision for the next major version of the language, one which opens up the language to new audiences.

I personally don’t think Scala 3 would be compelling if it were just “Scala 2.x” plus a few individual and isolated SIPs. This is a critical period of evolution for the language and the processes that worked well for maintenance of Scala 2.x could never bring us Scala 3.

As for older SIPs prototyped on Scala 2.x or not prototyped at all, it is unfortunate some of them may be lost or deferred to post 3.0, but this is expected for a feature freeze; and it is similar to an aged pull request that must be closed for now because the merge has become non-trivial. This can be understandably frustrating and disappointing, but it’s a necessary (if unfortunate) consequence of finite time and resources.