Why should return 1 + 2 be parsed as (return 1) + 2, though? It would require you to write return (1 + 2) each time. To me, that is much less intuitive and useful.
I rather like Scala 2’s syntax, even though I’m still wary of Scala 3’s new syntax, and I can’t tell exactly what you’re referring to in your answer. What particular complaints do you have about optional braces?
I agree that 2 vs 3 doesn’t matter much.
2 spaces make it hard to tell just how indented something is.
3 spaces make it kinda hard to tell, and deeply indented stuff has too much whitespace in front.
4 spaces makes it pretty easy to tell, but deeply indented stuff is hardly even on the screen any more (at 80 characters–I frequently have indents ten deep, which is half the available space at 4-space indents!).
The way to solve this issue is to get scala syntax mode in editors to include stronger vertical patterning to indicate indent levels. Then you can tell how indented something is.
(“But it doesn’t work with every editor already!” isn’t a very good counterargument since a lot of editors already don’t expect 3-space indents.)
Indentation width is probably comparably contentious to discussions about maximum line lengths. Why not make the required/expected indent (2, 3, 4) a compiler-flag, with a rewrite rule to go from one to the other?
@odersky, would you please consider adding some rationale on why the .. proposal is not in the running anymore (apparently)?
I simply don’t think it would work better than what was chosen, and at this late point we should be way beyond considering more changes.
Sure, that much is clear from the lack of answer, but it seems to me that the other proposals received more in-depth consideration (or at least responses), which, given the excitement that was there for its potential to break the stalemate, was surprising.
4 spaces makes it pretty easy to tell, but deeply indented stuff is hardly even on the screen any more (at 80 characters–I frequently have indents ten deep, which is half the available space at 4-space indents!).
I kind of like how it pushes me to extract code into discrete methods. “And besides”, Python gets away with four spaces. Ancient Java/Go uses eight AFAIK.
Again, idiomatic Python code (imperative, statement-based) is extremely different from idiomatic Scala code (functional, expression-based). Python doesn’t even have multi-line lambdas, which would be absolutely unthinkable in Scala. So you can’t expect Python experience to apply to Scala here.
In my experience the difference in style (imperative/functional) does not necessarily equate to a lower/higher tolerance of indentation. Python nests if-, for- and context-statements several levels.
On another note, you could also argue that having deeply nested structures with too little indentation makes everything harder to read.
With all due respect, the feedback is arriving so late because no opportunity to provide it was given until “this late point”, so it seems odd to chastise someone for that.
If considering more changes is out, and it’s been made clear that this is not a go/no go check in with the community, could you clarify what exactly the point of this thread is? The title “Feedback sought: Optional Braces” doesn’t really seem to fit if “considering more changes” is off the table.
We had a very productive discussion with 331 messages and arrived at a great outcome. I am really glad we had the discussion. I am also happy to take further comments but I won’t put myself under the obligation to respond to each of them individually. I have already written a lot on this thread, probably too much. If there are major new developments, I’ll re-engage.
I’m not sure how you got to that conclusion. There’s been 3 mostly separate discussions, none of which have been particularly productive.
Initially, there was a bunch of chatter about how this was an incomplete feature, and questions about if this could be moved under a compiler flag to give it more time to mature. This line of discussion was unproductive because it was shut down due to the expense of changing documentation, rather than those concerns being addressed directly.
There was a largely separate discussion about block delimiters, appears to have died out without accomplishing much of anything in terms of consensus, and it turns out was mostly irrelevant anyway because this feedback came “too late” in the process.
Indentation made a brief appearance, but this discussion was also largely unproductive. As far as I can tell, it’s something that won’t be relevant for years, because most editors choose syntax highlighting and indentation based on extension, so a full switch won’t be possible until everyone is on Scala 3.
So, while we have had 300+ messages about this topic, the outcome appears to have been predetermined (because you’ve explicitly said this), we just weren’t informed of this ahead of time. That’s neither productive, nor a particularly great outcome, as community consensus doesn’t appear to have been reached, and change was off the table from the start.
Dotty has been available for use for as long as there was compiled code. I presume the premise of this discussion is gathering feedback from people who have been taken the opportunity to experiment with it as it evolved throughout the years rather than asking people to look at it for the first time and give feedback on it. A criticism on the design that exists rather than a request for new ideas around the concept.
There were specification changes as result of the feedback given, so clearly it was productive: it produced a changed.
Replying to feedback isn’t really part of the process, unless clarification is needed. Nor is addressing every concern raised. The person/people requesting feedback might triage feedback based on whether it is actionable, or if it has been discussed before.
Community consensus is not a goal.Convincing or appeasing people is not a goal. Some messages here seem to be demanding satisfaction, which is entirely out of scope of what a request for feedback thread is. As is this message, for that matter, but I hope this helps people reframe what the goal here is.
And, disclaimer, I’m just an interested third party, and Odersky or others in the language committee might well step on me and refute some or all of what I said.
Yeah, I also don’t see what the great outcome is supposed to be. Seems like all details were already decided before they were even discussed, or did I miss something?
The only new thing I see is the idea of changing the indentation to maybe three spaces, but that’s not a language feature, because the compiler doesn’t care how many spaces it is.
Looks like we should update the documentation of the Scala Improvement Process to reflect that Martin is the BDFL. And where does the idea of a BDFL come from? Python, of course. Except that now even Python moved on from that.
That’s unfortunately not how this played out. Attempts at giving feedback were tried well over a year ago, and were rebuffed as not being the appropriate time to provide feedback. For some of the folks in this thread, this may well be their first look at the feature, however there’s a substantial number of very familiar names in this thread from the other attempts at providing ad-hoc feedback.
Part of the problem is the goals were not made clear, nor was the scope of acceptable areas of discussion, which is why I’m asking clarification on what was expected here. Even in this thread, you’ll find at the very beginning feedback was given on the existing design - we stopped doing that when it became clear it was not something the language committee was interested in hearing.
At least for my own part, I started this thread with the hope that it would be treated much the same way that recent threads on given have been: feedback was gathered and a either concerted effort was made to convince the community that the existing implementation was good, or experiments were done to produce something that the community could be convinced was good. That simply hasn’t happened here, so the questions left are “Why not?”, “What is different about this?”, and “How can this be communicated next time?”.
Honestly, it would have been much different if the initial post had included something which expressed the limitations that have been surfaced during the subsequent 300+ messages - possibly along the lines of “This will be standard and recommended syntax, hiding it behind a compiler flag is a non-starter, and we consider it too late in the process to make anything other than minor tweaks to the syntax.” - mostly because I (and likely others) would have known up front that logging a symbolic objection is all we could reasonably hope for, and it would have saved everyone a bunch of time and frustration.
While it would be a lie to say I’m happy about how this turned out, I accept that there’s literally nothing I can do to change this. What I might be able to do is make enough of a stink to hopefully prevent this from happening next time, either through more timely feedback opportunities or more clear expectations.
I extract code into discrete methods when it makes sense. I don’t deeply nest things for fun. It doesn’t take much to get ten deep when using lambdas to select what you need. Don’t you have lists of lists of objects with optional lists of things with optional things, where you want to get/do something with those innermost things? It’s really very easy to deal with this with nesting. Having to write one-off methods instead raises the burden by an order of magnitude, with no increase in clarity. (Maybe even loss of clarity, because you think it might be relevant somewhere else.)
Keep in mind that we have had a good deal of discussion about drawbacks, and that people who like : just aren’t convinced by the arguments that it looks like type ascription, and leads to confusing ad-hoc rules about where to use : and where to use nothing.
I don’t think this is terribly different from the discussion on given. The difference is that with given, before it was called given, there were lots of people saying “argh no!” and giving decent arguments about why. Here there are lots of people just saying, “I don’t find that argument convincing. I like : anyway.”
The difference with given, aside from it being too late to change things without a lot of effort, and time being very short as well, is that a lot of people like the : syntax. I personally find it abhorrent, but I have an easy solution: I won’t use it personally. I’ll just use braces anywhere : is required. Any other team that finds it confusing can make the same choice.
This isn’t quite as bad as it seems. Code formatters should be able to switch back and forth, and you’ll have to learn to read both styles anyway. I’m kind of sorry to not be able to use the syntax in places where it would otherwise make sense, but oh well. If a language has a visually confusing, irregular, optional new feature, just don’t use it!
Unfortunately, the biggest difference is that there’s no equivalent to this statement in the thread on given:
Which really undercuts the whole discussion, because it clearly states that the arguments presented against : were entirely irrelevant to the outcome of the discussion.
What are you trying to achieve? That might help the feedback get to the ear that needs to hear it.
If you want a change in process, take it to the SIP.
If you want a change in syntax or semantics, create a ticket (scala, dotty, or dotty feature request).
(Edited for length and clarity.)
I don’t have any particular expectation there will be a change in syntax or semantics, and (at least as I understand them) the processes in place should have already prevented this from happening. What I am trying to achieve is much simpler: keeping everyone accountable about what happened, because if we pretend this was somehow a productive discussion with a great outcome, it’s more likely to happen next time. Ideally, there’d be a post-mortem, but while I thought about created a dedicated thread for that, I’m pretty sure it’s not my place to initiate such an effort, and attempting to do so would kill any hope it might have of being effective.
I don’t actually know what this means 
Whatever you’re on, I want some.