if you want to know more about or help and support the SIP Committee work, please come chat with me at https://gitter.im/scala/center. 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:
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 https://gitter.im/scala/center.
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.
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:
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.
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.
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.
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?
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.
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 https://gitter.im/scala/center.
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.
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.
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.
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ā
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.