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 https://dotty.epfl.ch/docs/reference/overview.html 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?
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.
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 docs.scala-lang.org is premature I think, but I do hope I can have a PR ready when that happens.
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.
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?
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:
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.