“Classic curlies”. I think we have a winner.
Let’s update ScalaDoc? Or maybe we can immortalize both on two slabs of marble?
Thanks for the additional use-case descriptions!
Yes, if we keep the rewrites, we should probably test them better. But all of that is work, which I was precisely trying to avoid with the initial question 
Why not just “braces syntax” and “indent syntax”? Seems to me that adding “classic" doesn’t make things clearer.
1 Like
Why not just “braces syntax” and “indent syntax”? Seems to me that adding “classic" doesn’t make things clearer.
I was kidding Matt; perhaps I just have issued an irony alert
2 Likes
There will always be work, and personally, I always try to avoid extra work too. The question is how to avoid extra work and one way is to test better.
1 Like
I wouldn’t call it a trap. It’s not done for bad reasons. Sometimes it’s just necessary to nudge users in a certain direction when staying in-between is worse than choosing any of the options.
And this is also my answer to @som-snytt . I’m fine with any of the syntaxes - in fact I’d probably prefer the old one more (I don’t assign any negative meaning to the word “old”). But I believe Scala should have only one syntax in the end and we should motivate people to migrate to it.
Well-intentioned traps are still traps, and they tend to be patronizing as a nice “bonus”.
The implication that the braceless syntax should be the one that’s favored relies on a bunch of assumptions that are unproven at best, and flagrantly ignore reality at worst.
4 Likes
The compiler doing re-writing of the code is awkward. In my view of what a compiler should do, modifying the original source files is not included. For one, because it leaves the local repository with uncommitted changes, and as soon as that happens, we also need a test in CI that fails the build in case the source files are changed.
Re-writing should be the job of a separate tool, like Scalafmt. Also, it should ideally work well in both directions. This isn’t just because people may change their minds; another practical consideration is to backport code to Scala 2.x, which will be with us for a very, very long time. Some of us will probably retire before Scala 2.x projects are no longer actively maintained.
And the “old” / classic syntax will be around for as long as Scala 3+ wants to be Scala, instead of a completely new language. That’s how languages work, I don’t make the rules 
6 Likes
After quite some time of adjustment I now, eventually, just love the indentation-based syntax including occasionally using colon instead of a block as in “fewer braces”, if I run out of horizontal space etc. To me, indentation-based syntax means: less clutter - easier reading - quicker comprehension.
But that’s a personal, subjective view and others seem to have very strong views on braces being crucial syntax for them when they read code. I doubt that we soon will find any objective, corroborated cognitive evidence that a certain syntax on average is easier to read/comprehend, although such empirical research would be really interesting ) )
As a large part of the community seems to want to keep using braces, and that the brace-based syntax was promised to never go away ever, I think it would be a service to the community to make it easy to switch between syntax modes – it’s “just syntax” TM – as long as there is a back-and-forth semantically unambiguous mapping between the two. It would be an unnecessary risk of “scaring away” a part of the community, not to support both modes.
Then I view it as an implementation detail, if it is the compiler or scalafmt that provides the functionality; the goal is to pragmatically empower the users to be in control of their code; the requirement/wish/need is to support code bases that include both modes or want to switch between modes with good round-trip tooling. How that is implemented should be based on what enables the best support for the user, after analysis of real-world use cases etc.
It would be cool if there was a shortcut in VS Code or IntelliJ that with a simple keystroke toggled the different syntax modes, or as a kind of “presentation setting”. Then both camps can have the cake and eat it.
This functionality has a cost – but it also has a value from the viewpoint of many users. Given the eternal epic controversy 
of braces vs indentation, I think it seems worth it to carry the maintenance cost of supporting syntax mode round-trip in this case. After all Scala is the pragmatic language TM 
4 Likes
I think it is important, given the many strong views and that this functionality helps people with different views “co-exist” with less friction and help adapt code to their personal ergonomics or team coding standards.
4 Likes
Additionally, continued support for a functional round-trip (and any work towards a polished round-trip, as it’s functionality is limited if any time a round-trip occurs it creates a massive diff in every file in the project) will help build trust that assurances that the standard syntax will not be phased out are more than just empty words.
Building and maintaining a highway to onboard projects to fewer-braces syntax and either removing the return trip (or allowing it to degrade) would be a strong signal that those assurances were empty promises offered to end an uncomfortable discussion.
Here is an update about my work on fixing the known and unknown bugs of the -ident -rewrite
While fixing #17456, I found a whole bunch of bugs and unintended behaviors in the -indent -rewrite of Dotty. So I rolled up my sleeves and started fixing all of them, and I am currently in the process of testing the rewrite in the community build.
The resulting PR (still a draft) is:
I am quite happy with the result as I am now able to rewrite the dotty repo to indent, and other big libraries of the ecosystem (scalatest, zio and more)
What about the -no-indent rewrite ? There are no known bugs in the -no-indent rewrite currently, and adding braces around regions seems a lot easier to implement/maintain than removing them.
What would it take to move the indent and no-indent rewrite out of Dotty to Scalafix? It would at least require some significant effort to re-implement all the little corner cases. And we would lose the testing infrastructure that we have in Dotty, that ensures there is no regression between any two versions of the compiler. Plus it would raise the questions of the target Scala versions: should we target 3.0, and/or 3.3 (fewer braces)? What about future versions?
All in all I think it is not worth extracting the syntax rewrites out of the compiler. I am confident that we can make the syntax rewrites reliable in the compiler itself. Of course scalafmt can also rewrite to indent, but it rewrites the entirety of the code (not just remove the braces).
10 Likes
Great news to hear that a lot of these bugs have been fixed in the compiler!
IMO, the fact that you found so many is due to the fact that you tried applied the rewriting capability on a lot of “real” code (part of the community build). I proposed exactly that earlier in the discussions on this topic and I really appreciate that someone picked it up. Is this now part of the community build?
As for removing the rewrite feature from the compiler itself and moving it to Scalafix:
Pro: It would simplify the compiler code making it easier to maintain and evolve.
Con: If, as you suggest, it represents a significant effort with the risk on ending up with an incomplete implementation, that wouldn’t be great… (although, if this implementation is tested in the community build by doing round-trip rewrites, this risk is probably pretty low).
If the choice would be to implement rewriting outside of the compiler, I would be inclined to favour the Scalafix route; implementing it in Scalafmt would require to implement the missing rewrite from significant indentation/new control structures syntax to curly braces/old control structures syntax. Also, Scalafmt configuration is a beast. For example, just figuring out from the docs that the inverse rewrite isn’t available took me a lot of time. A new Scalafix rule would be much cleaner in that respect.
Finally, and for the sake of completeness, one good thing about the Scalafmt rewrite implementation is that it’s a single step process. Not sure if that this could also be implemented for rewrites with the Scala compiler.
2 Likes