While that’s a fair distinction to make generally, I don’t think it’s a particularly useful one to make in this case because there hasn’t been an opportunity for feedback by the community at large, other than a few threads like this where the vocal subset have attempted to force the issue to the forefront, mostly unsuccessfully.
This is also part of the reason that, speaking for my own concerns, this is being brought up in the context of significant whitespace and not one of the other big changes (e.g. givens) because those have generally been subject to lively debate and many of the suggestions and concerns raised in those discussions have been incorporated into (and generally improved) the resulting designs.
Stated another way, while the other big changes may not have adhered to the letter of the SIP process, they’ve stuck close to the spirit of that process. The way that significant whitespace has been handled departs from both, and that’s extremely unsettling because, while you may feel that it’s a trivial change as a language designer, as a language user I haven’t found that to be the case, and I’m clearly not the only one.
I would have said the same about infix at the start of this process . The problem is that, if a change as big as significant whitespace can be made without getting community feedback, it creates the very uncomfortable precedent that anything less disruptive that this can be done if @odersky reads a paper he finds particularly convincing and has a few weekends to spare.
Please prove to me that the majority of the community dislikes optional braces for all cases.
You’re just choosing an arbitrary default here (assume no change unless majority provably wants it), and then you’re implicitly leveling an accusation against the language designers (ignoring the community) because they didn’t choose the same arbitrary default as you did. And again, that’s a very very serious accusation to make over a feature as trivial as significant whitespace. Why aren’t you making this argument about something more substantial, such as the elimination of higher-rank existential types? Or the severe restrictions on type projections? Or the addition of multiple implicit parameter blocks (and unfixing their location from the end)?
I can assure you that significant whitespace has been the source of much more significant ire and debate than almost anything else. That’s not to say that anything has made it into the language without careful examination, but your characterization is exactly backwards. The change was made very carefully, and the community has been loudly involved since it was first publicly mooted. I’m not sure exactly what you want here. Everyone’s voices are being heard, it’s simply that the language authors don’t agree with you.
Let me put this a different way: simply because their opinion differs from your own does not mean they have acted impulsively or unilaterally. They just… don’t agree with you.
Have you used Scala 3? Or, alternatively, have you used Scala 2 without significant whitespace? (seeing as the language already has elements of this)
First off, that’s quite uncharitable to Martin. I can honestly say that I’ve never met anyone who considers changes for longer or more deeply or carefully than he does. Even syntactic changes go through a lot of consideration before he proposes them, much less commits to the compiler.
Second, the entire Scala community uses (and seems to like!) significant whitespace and has since the beginning. Semicolon optionality only works due to magic newline and double-newline semantics. It’s not at all a stretch to see this, fundamentally, as an extension of that very popular feature. From that perspective, this feature has been in consideration for a decade and a half.
That’s simply incorrect. There’s never been a, “what do you all think about this?” on the subject. The change was initially introduced as, “this is something we’re experimenting with, and will gather feedback on in a few months.” That was literally years ago at this point, and the last time it was even mentioned before the comment that sparked this thread was about a year ago, when it got a brief mention in a survey of 2nd year CS students.
Yes, immediately after this was introduced and we were asked to try it out, with the anticipation that there would be an opportunity to provide feedback. This opportunity never materialized.
Nobody is perfect, or perfectly consistent. While @odersky is generally very conscientious about this sort of thing, this time doesn’t seem to follow that pattern. As far as I can tell, @lihaoyi created an experimental project exploring significant whitespace back in 2013, Martin found it at some point and decided to experiment with it, never got around to refining it (even @lihaoyihas reservations about the current implementation ), and at some point the powers that be just sort of assumed everyone was on board with it.
The problem was, they never actually got community feedback. Because of this, a bunch of irregularities never had a chance to be ironed out, and we’re heading into Scala 3 with a new default that’s highly irregular, and that stands out particularly starkly because of all of the other changes that have been careful to increase the language’s regularity.
So while that might not be a fair characterization of Martin’s default behavior, at least from the outside it’s happened once, and what has happened once can generally happen twice.
Addendum:
Note that, while significant whitespace is generally accepted as a good thing, that’s not what this change is about. It’s about significant indentation, which is a different kettle of fish. I’ll try to be more intentional about not mixing terms.
You are implying the vocal subset is different from the community. How do you know it is? What if the majority of the community hates the change? There is a process to help to find out. Any one who wants to avoid the process exposes themselves to the suspicion that they wouldn’t like the outcome of the process.
The status quo prevails until a decision is made to change things - and there is supposed to be a process for change. Therefore, the default should not be arbitrary.
What is the relevance of this what-about-ism? Of course, I am also against other changes without proper process or proper community feedback. Also, as I said before: some changes were maybe an inevitable consequence of the decision to change the backend. The syntax was most definitely not.
I don’t think any amount of argument here will convince either side that the majority of the entire community welcomes, or loathes, optional-WS. Only a tiny amount of the community visits these forums for example. We can speak for ourselves and our circles but that’s about it unless you’re out there doing surveys. It’s moot in this context, isn’t it?
Even any kind of assertion from Martin himself that braces will remain in 4.0 is moot because it wouldn’t be some legally-binding contract. It would just be a prediction about the future. If all kinds of new information came in over the next 10 years to change that prediction does anyone really think Martin or anyone else would say “well, it’s overwhelming a good idea but we’d better not do it because I said on a forum many years ago that I wouldn’t.” I understand wanting assurances but even if it were promised it would be unrealistic.
Instead wouldn’t the path to consensus be to
clarify how the SIP process will be involved now that we’re at the tail-end of Scala experimentation and design. (I commented further down the mountain in more detail about this and I think this is really important.)
consider if putting optional-ws behind a -Y flag would satisfy the majority of both camps.
I have just opened a formal feedback thread on optional braces. Quoting the last paragraph of that post:
I also apologize for having sought feedback so late in the game. We dropped the ball on this one. It was because due to Covid all SIP activity was dormant since March 11th. We should have opened this thread over the summer, but nobody thought of it then.
. The problem is that, if a change as big as significant whitespace can be made without getting community feedback, it creates the very uncomfortable precedent that anything less disruptive that this can be done if @odersky reads a paper he finds particularly convincing and has a few weekends to spare.