Scala 3 feature status overview

I’m tremendously happy with the speed we’re seeing minutes of SIP meetings. A big thanks for getting that on the road.

While having these minutes is great, it painfully shines a light on how difficult it is to get an overview of features/proposals for scala 3 and their state. I’d like to volunteer to get that on the road. I appreciate that there is immense pressure on the inside to get things done and not a lot of spare capacity to deal with providing this kind of transparency. I’d like to make documentation on

  • What the SIP committee is doing (i.e. determining which features will be part of scala 3.0) and not doing at the moment (things that are not directly involved in what will be in scala 3.0)
  • The list of features that has or will go through the SIP committee
  • The status of each such feature: To do -> For feedback on discourse -> ready for SIP meeting -> accepted for 3.0, accepted for 3.x, rejected without prejudice/delayed after 3.0, rejected with prejudice, back for further iteration

Is someone in the SIP committee willing to help me with this and review documentation PRs? Is my characterization of the current role of the SIP committee correct? Is the list of features on a good approximation of features that are in any of the above mentioned states, or does it need more git archeology and minute-digging to determine rejected proposals fully?


Suggestion: use a (large) spreadsheet for the status.

I’m not too worried about the technology. I’m more worried about finding out from minutes what proposals exist or existed in what state.

The retreat had a list of “easy proposals” that I assume were accepted by acclamation but for the rest, I can’t determine of any of the proposals if there was a vote, and if so, what the actual outcome was. (The closest I get is for @infix where the minutes say that nobody seems to be really against, so accepted by acclamation, but then goes on with some discussion on when to enforce. Whether Marins suggestion to given allow non @infix methods to be used as infix in 3.0 only, and only if the argument is in braces was actually accepted by the committee, I can’t determine.)

If anyone on the committee is willing to volunteer their time to indicate of each of those whether they are accepted for 3.0, accepted for 3.x, up for further discussion, rejected for 3.x entirely, or just rejected for 3.0 but open for resubmission later k the 3.x cycle (or that it simply doesn’t work that way) I’d be happy to take at least maintaining the list with outcomes for them.

1 Like

We had a spreadsheet for discussion at the previous SIP meetings. A link to a condensed version is here:

I should emphasize that no formal voting has taken place yet, so the “tendency” column was derived from straw polls of committee members. It might still change in some ways, particularly if new arguments come up in public discussions here.

The next steps will be to open threads about features that did not have a public discussion period yet.


That’s great Martin, thank you! If I understand correctly that’s the full list of features that need to be approved for 3.0 and straw polling on the acceptance of each of those.

Getting some features nailed down as “accepted for 3.0” would be a big deal IMO. Is that likely to happen in the next SIP meeting? Or maybe even by mail-in voting?

As long as no features are fully accepted yet by vote, documenting them on is premature I think, but I do hope I can have a PR ready when that happens.

Summarizing the doc per status (where the status is strawpoll status), I come to

Finalized and accept for 3.0

  • implicit function types
  • dependent function types
  • drop auto application
  • drop class shadowing
  • intersection types
  • union types
  • drop compound types
  • trait parameters
  • drop early initializers
  • drop existential types
  • drop procedure syntax
  • drop symbol literals
  • drop type projections
  • enums (rly? with/without widening apply/nesting?)
  • eta expansion
  • extension methods (has the bikeshed been fully painted?)
  • given instances
  • given import
  • using clauses
  • kind polymorphism
  • name based pattern matching
  • opaque type aliases
  • type lambdas
  • harmonization instead of weak conformance
  • main functions (with or without some form of parameter parsing)
  • toplevel defs (modulo details)

accepted for 3.1

  • drop xml syntax

rejected for 3.0 without prejudice

  • erased terms (probably 3.1)
  • nullability (feature not ready)
  • numeric literals (probably 3.1)
  • drop auto tupling (scala 2 world not ready)
  • named type arguments (unlikely to be re-submitted, as close as rejected with prejudice as it gets)

no consensus or no (closed) public discussion

  • @alpha
  • creator applications
  • drop DelayedInit
  • drop do…while
  • drop non-local return
  • export clauses
  • Conversion
  • implicit resolution changes (minutes suggest these should be split in all individual cases?)
  • indentation syntax
  • main functions
  • match types
  • meta programming
  • multiversal equality
  • parameter untupling
  • pattern bindings
  • polymorphic function types
  • structural types
  • wildcard types with ?

(edits reflect Martins corrections)


Thanks for the summary! This looks accurate to me. I just have some more nuance to give on rejected items:

  • named type arguments look dead for now.
  • nullability and drop auto-tupling: High interest to have this, but implementations are not mature enough to promise this in 3.0. In the case of dropping auto-tupling, it’s mostly that migration might pose problems.
  • erased terms and numeric literals are deferred, expected to be resubmitted for 3.1 or later.

We’ll try to have delayed features in the 3.0 release, but enabled with a command-line flag or language import.

The way the SIP committee works is that we try to achieve consensus. So it’s hard to give a timeline when votes will take place. But I hope that we will have most things tied down by the time of the next Scala meeting, probably in July (impossible to say for sure in the current situation).

Anyway, if a feature has “accepted” as a tendency and has been discussed publicly, it’s a fairly safe bet that it will stay in.

I made some updates based on those comments. The accepted section is just a gavel strike away from actually being confirmed full-fledged scala 3.0 features, but I nevertheless really look forward for that gavel.

Neat! Is there a key to the F / R / S / C values in the “Why 3.0?” column?

Mouse over the column header - it’s in a note there.


I’m not sure if that’s a good place to ask, but what happened to them? It sounds like really useful feature to overcome issues with type inference. Is it just because work has stopped due to other priorities or there is some fundamental issue with this feature?


If you hover over the column title, you should see the explanation.

The committee was not convinced enough it’s worth it, and better than alternatives like curried type arguments. So the proposal was withdrawn, since furthermore there is no hard reason it should be in 3.0.

So it’s not refused outright, but there’s no current activity to bring it back

Missing the change in lazy values (also never discussed on any public forum I’ve seen). In dotty lazy vals can be abstract while in Scala 2 not, and only lazy values can implement / override abstract lazy vals:

I’d say that’s a bug in Scala 2 not a feature of Dotty :).

This is necessary for soundness, so it’s not something we can change.


Fun fact: you can fake this using Macros!

Mill relies heavily on def foo = T{...} behaving like a lazy val that can be overriden and call super.. It just gives each such def a unique ID and stores the computed value in an instance-level dictionary so it is computed once and re-used forever after.

The only thing you need macros for is to assign each def its unique key. IIRc Mill uses a tuple of (defining class, method name) to do so, but other keys are possible

This lazy val overriding limitation has been causing problems back to the SBT 0.7 era; you can find other workarounds in those ancient documents. Glad to see it finally being addressed in the language!


Regarding enums: The question whether an enum apply should widen or not was left open. The current implementation widens. @smarter will try to make some changes to type inference that would make a non-widening implementation feasible. If that works out we will reconsider the question.