Preparing for Feature Freeze

And I have stated again in the beginning of this thread that they will go through the SIP process, which means that they go through public review and the SIP committee will vote on them. The SIP committee has also agreed that the mechanics how these proposal are treated will have to be streamlined in order to do this in reasonable time and effort.

The issue is that we started from a very unusual point. The standard SIP procedure (in very abbreviated form) is that someone makes a proposal for a single improvement, the proposal is documented and implemented in the Scala compiler, and then the SIP committee votes on it. But that’s not how Dotty happened. Dotty was its own language and code base with no relationship to the SIP process. About 18 months ago there was a collective decision of the relevant contributors of Scala 2 and Dotty that this codebase and feature set would become the basis for Scala 3. Another question was whether the SIP committee, which was up to that time only concerned with the evolution of Scala 2.x, should get involved with Scala 3 also. After some deliberation we decided that the answer should be yes, but that the process would have to be adapted to account for where this is coming from. Unlike with normal SIP features, everything is already implemented in one codebase and documented in one repository. Since that repository already exists, we will take it as the basis for tracking the state of the approval processes.

Concretely, each topic in the Dotty reference is treated like a separate SIP proposal. It is discussed by the SIP committee and if it passes a first round of review it will be submitted for public review. Sometimes major refinements will be needed (as in the implicits proposals) in which case the process can repeat. At the end, the SIP committee will vote on the feature. For better transparency, we are about to add status information about the current state of the approval process to each of these pages.

We will have to evaluate whether we also want to use a different scheme for proposals by others. It seems the scheme we currently have could be improved. I take note that the SIP committee should make a better effort to keep the set of pending SIPs up-to-date and moving along.

If one of the currently open SIPs should still be considered for 3.0, we would need to see a pull request against the Dotty codebase. The PR should contain a doc page, in the format of the Dotty language reference. We will make sure that the SIP committee considers any proposals that are updated in this way.

One final note of clarification: The SIP process decides what goes into the Scala language in general. It is not directly concerned with what improvement goes into which release. That’s for the maintainers of the released compiler version to decide.

4 Likes