Thank you for the acknowledgement of the process issues this feature has experienced, for a while it felt a lot like gaslighting, and was a deeply disorienting and unsettling experience, and it’s helpful to clear the air.
My experience with this feature has been that, the more I used it, the less I liked it. This, admittedly, may be partially due to my background, as I’ve worked in Python and Ruby prior to Scala, and this feature runs headlong into some of the least pleasant parts of the syntax of both those languages.
I don’t consider this a complete feature. This may be due to coming in before the rebranding to “optional braces”, as when I was experimenting with this it was treating it as “significant whitespace” and the concerns I encountered while evaluating it under those criteria have stuck, mostly because I haven’t really seen anything that would resolve them.
When I was experimenting with this, it hit the sweet spot of covering enough cases to look good in most of the sample code, while repeatedly running into situations where the whitespace wasn’t sufficient. I found this really detrimental to the legibility of the code. The problem is that, at least for me, it’s much harder to see what isn’t there, so blocks delimited only by indentation tended to bleed together. This was worsened when some of the blocks had braces and some didn’t, because when looking for boundaries the braces made the whitespace differences even harder to spot.
Refactoring was unpleasant, as was having to manage indentation. These are familiar problems for me from working in Python, and tooling hasn’t really improved much over “select the region and hit tab until it lines up”. Compared to “paste and hit Ctrl-Opt-L” (note: that’s my scalafmt hotkey), moving code around was much slower. Given the popularity of Python, if tooling improvements haven’t materialized by now, Scala adopting significant whitespace is unlikely to change that. Bottom line is that this moves indentation and formatting from “stuff I don’t have to think about” to “stuff I have to actively manage”, which is not generally the direction of progress.
Similar to Ruby, even when it became possible to skip the braces for function calls with the appropriate compiler flag, the code is deeply ugly when multiple parameter blocks or even method chaining come into play. Both tend to come up in my code fairly often, which is a problem for me, due to the issues intermixing the styles I mentioned previously. As an aside, I don’t have the same issues with the cases where curly braces are optional now, because they only apply when the block would contain a single expression, and those tend to be visually distinct.
Given this irregularities, I don’t see how adding this is consistent with changes like removing infix flexibility. It adds way more variability and irregularity than infix syntax, and BDFL or not, I can’t shake the impression that this is getting in because it’s new and shiny, rather than on its own merits.
Call it out as an experiment and put it behind a feature or language import, if it’s really as compelling as you think, it’ll get adopted. If not, that sets up an easy way for people to try it out, and time to figure out how to fix the places it currently underperforms. I’d be behind that 100%, because the places where this really shines for me is code that doesn’t have the characteristics mentioned above: embedded DSLs, and it would be handy to be able to opt-in on a file-by-file basis (block by block would be better, but that’s probably an unreasonable ask).