I’d prefer one clear option as well, to be honest.
The way forward that seems least disruptive to the scala ecosystem would be to restore the unpopular but unambiguous version, start a versioned/RFC process and then make changes through that. I understand if there’s resistance to that, as it’s a significant amount of work.
The way forward that seems least disruptive to the scala ecosystem would be to restore the unpopular but unambiguous version, start a versioned/RFC process and then make changes through that. I understand if there’s resistance to that, as it’s a significant amount of work.
This is a great idea.
I’d like to see a Committee choosing a formatting standard that can be enforced with a tool. In my opinion, the SIP Committee is not the best candidate to participate in this initiative, and I would prefer to create a new one on purpose whose members come mainly from the Scala community.
@eddsteel If this project is to move forward, would you like to participate as the lead of that hypothetical Scala Formatting Committee (SFC)? Your responsibilities would be to mediate and strive for progress in the discussions.
I would be happy to mentor/help whomever decides to move this forward.
I’m also a fan of similar approaches (like gofmt). Especially on the specific matter of Scaladoc comment style, automatic consistency is most of what matters—or you’ll suffer from the effects of Wadler’s law.
OTOH, I suspect codesigning style and syntax might help get a consistent style, and that’s not always an option.
I really like all the ideas here.
Most importantly I like the idea of versioning the guide. At the very least this means that tooling can then specify the exact version of the guide they conform too, if some tool is out of date, instantly the user knows which version the tool conforms too and can then inform the tool creator of the update.
I’ve looked into how the Rust community handled this issue. It seems that they created a style team deliberately to pick the formatting standard, the same approach I was proposing with the “Committee”.
I think the best way to move this forward is to put together a SIP-like document that will discuss the governance of this process and who would be part of it (very similar to the document the Rust folks have done).
With that document, we can have an open review from the Community and then pick the Community members that will be in the Scala style team.
What do folks think about this approach? Suggestions?
Unlike the Rust community we’re starting with a fairly mature code formatter (thanks @olafurpg et al) and a fairly widely known and stable style guide, which is great!
If there’s a literate programming tool to tangle code blocks from markdown (I’m pretty confident there will be) then that combined with the existing style guide and scalafmt --test could produce a workable scalafmt config pretty fast and identify if there are any major areas that aren’t supported. I’d be happy to play around with that though it will probably not be until the weekend.
As far as governance goes I like what I’m hearing but don’t know much about this side of things. The Rust community has always seemed to work really effectively though!
Scalafmt enforces one code style that is not widely used in the Scala community. I know several project maintainers in big Scala codebases, both using and not using scalafmt, that do not follow the scalafmt defaults.
In my view, this issue is not about the code formatter itself, but rather about the community picking a standard formatting style that beginners and advanced users alike can use without thinking too much about it. This decision process needs to be lead by community members and volunteers, and it would finalize when the style team reaches consensus.
Yeah, I agree 
I really like the way the Rust community handles these scenarios. I’m trying to get some inspiration from them.
It seems you’re not interested in moving this forward at the “political” level (to write a SIP document to chair a style team and decide on the code style). So we’ll need to wait for someone to do so.
I am constrained on time lately so I can only help in the process, not lead it. The process would be as follows:
Any suggestion to that ideal process is welcome.
I think a blessed/standard style guide for a language defines the language just as much as its compiler/interpreter and standard library. So I think this is still within the realms of the existing SIP committee.
I think a blessed/standard style guide for a language defines the language just as much as its compiler/interpreter and standard library. So I think this is still within the realms of the existing SIP committee.
I disagree, there are clear differences between a standard style guide and a compiler/standard library. A style guide does not define the language in the same way. Users eventually define how to use a tool.
The same is true for languages – speakers shape languages over time. No matter how many language regulators are (the equivalent of the SIP Committee), what eventually matters is how the language is used in the real-world. That’s why I’m interested in capturing an agreed-upon, widely used style guide approved by the Community (the “language” speakers/writers). I want the standard code style to truly reflect the way people feel we should write Scala.
Therefore, I do not believe that the SIP Committee should take this decision. I would prefer a community-driven process. I would like the Community to have more prominence in this kind of decisions.
That being said, if the majority of the community does not want to go through the process of picking a style guide, I’m happy to discuss this issue in our next SIP meeting. But a discussion must take place first.
I’d very much like to see the style guide updated and synced up with scalafmt. As others have said, giving beginners a reasonable basis to start from and advanced users a way to avoid bike shedding is hugely valuable, especially if it can be supported by an automatic formatter.
I think a key element of this is realizing that there will have to be some compromise and that the goal is to have something to start from that isn’t terrible, as opposed to attempting to make everybody 100% happy. Nobody says you have to follow the style guide and associated scalafmt configuration, but lets make it really easy to do.
I’m happy to help however, including making a pass at writing a SIP if that ends up being the path that makes the most sense.
I had a go at a scalafmt config for the code examples. Gory details here.
With the following options most examples are accepted.
align=none
continuationIndent.extendSite = 2
But for some examples I couldn’t find a scalafmt option that would allow them – so they either need to change or scalafmt does. The big problem file is (as expected) the scaladoc one, which uses a format for which scalafmt does not have a named option.
In addition ... is used throughout as a placeholder which won’t compile and needs to be manually replaced – scalafmt needs a valid AST to work with. If people think ??? would be acceptable in these examples instead I can open a PR.
I don’t really have much to say on the “political” side of things regarding process but as far as technical feasibility this looks possible with some small changes to the existing style guide, and potentially some changes to scalafmt.
Nice work!
Alternatively, ... (triple dots wrapped in backticks) can be used as a replacement for …
I think there was a discussion to change continuationIndent.extendSite to 2 spaces by default for v1.0, so this only confirms it’s a good idea.
It seems to me Scala Exercises has such a literate programming tool.
You can compare here an example of source and rendered result by clicking on “View on GitHub”.