This RFC proposes a process for deciding detailed guidelines for code
formatting, and default settings for Rustfmt. The outcome of the process should
be an approved formatting style defined by a style guide and enforced by
Rustfmt.

Rendered: https://github.com/nrc/rfcs/blob/style/text/0000-style-rfcs.md

This answers my question on how to choose the right defaults for my take on rust-lang-nursery/rustfmt#298 then, I guess. 👍

Has anyone considered a kind of "crater for rustfmt"? We could take a sampling of crates and see how large the diff is when applying various defaults. That would give a sense of what the community actually thinks about style guidelines, when styling code by hand.

One question about the scope of RFCs: I imagine that there will be some topics -- such as appropriate places for line-breaking -- that cut across a lot of different areas, but which ought nonetheless to be considered as a unit. It seems like this would be a good topic for an RFC, but it seems to run somewhat counter to this wording:

RFCs should be self-contained and coherent, whilst being as small as possible to keep discussion focused. For example, an RFC on 'arithmetic and logic expressions' is about the right size; 'expressions' would be too big, and 'addition' would be too small.

I'm really excited about this approach to settling on a consensus format. While rustfmt is a useful tool even if everyone configures it differently, (1) defaults matter and (2) achieving community buy-in for a standard format can reduce needless friction in the ecosystem (e.g., as experienced when moving between projects that are styled in radically different ways). Standardized formatting, of course, been a point of pride for Go; I'm excited about taking a Rustaceous approach to get there, deciding via community-driven RFCs.

The RFC doesn't emphasize it other than in the summary, but a key point is that the proposed subteam is temporary and has a very clear end goal -- the production of a style guide that is enforced by rustfmt (at least in its default configuration). This is the first proposal for a "strike team":

Over time, we may want to expand the set of subteams, and it may make sense to have temporary "strike teams" that focus on a particular, limited task.

I think this is a great model for focusing the community's attention on an area that needs specific, limited work.

I was initially skeptical about introducing a separate RFC repo, but the detailed process that @nrc is proposing seems quite plausible, and does seem to profit from separating out the traffic from our existing venues. I like that we both end up with a single coherent specification (the style guide) but also have the repo for historical information about how we arrived at that consensus.

Probably my biggest concern is making sure we have a strong "overall vision" and not just isolated RFCs that don't coordinate well -- but I see that @nikomatsakis just made essentially the same point.

As a counter to the strong overall vision; I would worry, as a user of Rust, that any team made up of core Rust people would end up making a style which is similar to rustc style (which I personally, and many rust people I know, don't like), which I don't think is the right way to go. I'd much rather be able to speak in an open, RFC style, versus being dictated to.

@ubsan I think there must be some misunderstanding -- I wasn't suggesting that the overall vision should be set outside of the RFC process -- in fact I was saying the opposite. The RFCs in the strike team shouldn't necessarily be limited in the way that this RFC suggests, but should instead include style striketeam RFCs on the larger vision that the entire community can weigh in on.

IIRC the reason people don't like rustc style is because it isn't a style at all; it's a mishmash of styles from various points of time in the evolution of rust. New rust PRs seem to have a style more or less consistent with the ecosystem. Legacy style is irrelevant here.

I, like @aturon, was somewhat skeptical of a whole subteam and extra repo for coordinating this, but due to what I suspect is the high level of traffic this will receive that we'll want a high signal-to-noise ratio which somewhat necessitates splitting it from the main repo. In other words, it sounds like a reasonable idea to me!

@aturon Ah, then I'm fine :) I just didn't want a core team to override the feelings of the community.

@Manishearth No, I'm talking modern rustc style.

There is one thing I think rustfmt does wrong: removing trailing commas.

@ticki The only place I can think where rustfmt removes trailing commas is after curly-brace-blocks in match arms. In other contexts, like multi-line arrays or function argument lists (at definitions or calls), it adds commas so that every line ends in a comma.

It removes it in match blocks, enums, and struct IIRC.

@ticki I don't believe you recall correctly. See http://is.gd/b9IQdf and hit the format button. It makes sure every enum variant, every struct field, and every non-block match arm has a comma.

Like I said before, it removes the trailing comma after the curly-brace-block match arm only.

@durka Ah, yes, because it doesn't block-indent multiline argument lists by default. Nothing with the trailing delimiter on the same line would have a trailing comma. Presumably it would keep trailing commas in the case where you enabled that option, like this:

foo(
    some_long_expression(),
    long_enough_to_be_multiline(),
);

EDIT: If it removes them in this case with this option, it's just a simple bug/inconsistency with the handling of trailing commas elsewhere. Anyway, this is definitely a detail too specific for this general RFC.

This basically looks ok to me, with a few concerns:

This establishes an official team, with a page on the website and all, for a very narrow purpose. What's the purpose of creating a team? Do we feel that people won't be motivated to work on it if they don't get a picture on the web site? Do we feel that the team won't be seen as legitimate?

This RFC focuses on breaking down style decisions into very-fined grained decisions, but style is not such a local decision - every style decision affects the appearance of every other. I'd like this RFC to address how the overall quality will be kept in check. Just as an example, perhaps the team is maintaining a rustfmt'd integration test that exhaustively shows all styles together, that gets reviewed with each new RFC, or maybe a corpus of real-world code that does the same.

Hmm, not that I care too much, but I did not envision this strike team being listed on the web page along with the other teams, nor do I envision having the other "random bits of stuff" that come with a subteam (e.g. git alias). This is just because it's work to maintain and the team is temporary.

I think the purpose of having a team is just to clarify where the ultimate decision-making power on the matter of formatting decisions resides. (Like any team, I would expect that the process would be open, and would take into account objections from the entire community.)

So @wycats raised an interesting point in discussion. He -- and many others I know -- are of the opinion that rustfmt should not have any options; or, at minimum, if you want to have options, you should have to install a distinct tool (rustfmtx) to get them. The reason is basically that the value of having a common formatting tool is greatly enhanced if using the default options is basically universal. gofmt is an obvious example of a tool that has embraced this philosophy.

Now, it seems like settling this question is orthogonal to this particular RFC -- at least, it seemed so to me, at first. I imagined that we would settle this default question separately (personally, I'd probably like to remove the options, because I buy into that reasoning above, but I don't care that much tbh).

But @wycats pointed out that deciding on a particular default or format setting is very different in a context where you expect people to configure from another context. So if we wind up making this decision after a number of formatting decisions have been made, we might find we want to revisit those decisions.

Therefore, I'd like to propose that we discuss this question of whether to remove configurability a bit. I could imagine adding such a clause into this RFC itself. I could also imagine raising this question as one of the first points of discussion for the new team.

(Other than the point about options, I think that all of @rust-lang/core at least is pretty comfortable with the idea of formatting forming a subteam.)

EDIT: Corrected amusing typo. :)

… formatting a subteam.

😂

Now, it seems like settling this question is orthogonal to this particular RFC -- at least, it seemed so to me, at first. I imagined that we would settle this default question separately (personally, I'd probably like to remove the options, because I buy into that reasoning above, but I don't care that much tbh).

Wouldn't an option-less rustfmt require us to decide on a formatting profile, too, one way or another?

The problem with a tool like rustfmt and discussion on the default/only/etc style is that a ton of various corner cases will get overlooked. We recently had a bunch of PRs with rustfmt changes submitted to various parts of the compiler and rustfmt seemed to mess up a bunch of corner cases pretty badly.

Now I guess one could run rustfmt on rustc and then discuss all the nasty cases that arise, but you cannot obviously discuss all the possible corner cases that could be discovered, say, by running rustfmt on the whole crates.io ecosystem.

This is precisely the reason why I would be wary of making rustfmt defaults the only style at the moment, even if I don’t use the tool myself and don’t really care about the outcome of the “configurable or not? which style?” discussion.

@nagisa I would assume that the final rustfmt style will be the result of iteration and experience, and not just something that gets decided completely out of the blue. That is, I would think that we will run rustfmt on the entire compiler and report bugs for weird cases (and encourage others to do the same), no?

Therefore, I'd like to propose that we discuss this question of whether to remove configurability a bit. I could imagine adding such a clause into this RFC itself. I could also imagine raising this question as one of the first points of discussion for the new team.

I feel strongly that rustfmt should accept config options. I would never use rustfmt if I couldn't configure it to my liking. I do not understand what advantage there could be to maintaining a "rustfmtx" as a separate tool. I do not understand what advantages there could be to everyone in the community using a single formatting style (you say that it is a great advantage [emphasis yours] - can someone please explain this to me?). I do not understand, and find rather disconcerting, the attitude the Go community has adopted about code styling.

My previous comment is overly emphatic I think - I don't mean to seem intransigent.

I do not understand the argument in favor of having a non-configurable formatter. No one seems to ever make it explicitly, and I can't find anything on the internet which spells it out for me. This presentation contains a single sentence about code reviews which is entirely contrary to my experience. Maybe if someone could make the argument for not having config options, it would help me to understand.

To me, the attitude (more than any particular line of argument) taken by the Go developers toward gofmt suggests a devaluing of difference and of expression, two things I place high value on and want the communities I participate in to value as well. Obviously a formatting tool cannot in itself make value judgments, but since I've not seen anything but this attitude deployed in favor of non-configurable formatting tools, claiming that Rust should adopt one feels like claiming that the Rust community should devalue difference and expression.

@withoutboats I find it just plain easier to read a new codebase (and review code) when it's all in a style I'm accustomed to. If the entire ecosystem uses the same style and everyone is accustomed to the same style, the friction of jumping into other projects is somewhat reduced. I believe consistency in the ecosystem can have a much larger positive impact than tweaking the minutiae of formatting choices from project to project.

I think the comparison between pro-formatting consistency attitudes and attitudes that devalue difference and expression is entirely bogus. It's one thing if your code is intended as a work of art (I believe this does exist) and another if it's a project intended for everyone to hack on (in which case it's more welcoming to use the community style everyone knows).

I was previously part of the Ruby community and I'm now struck by how well Ruby had both - very consistent and strong opinions about style throughout, but also a fairly wide appreciation for code-as-art. An automated tool for formatting just makes the first part easier.

The only way I find this kind of thing agreeable is if this ends up like eslint and I can load the rustc formatting or the diesel formatting or my own project's formatting.

While I understand the point that one format makes life easy for new people coming to a codebase, as someone maintaining a codebase, I'm most interested in the ability of myself and other contributors to keep working on that codebase.

Many Rust developers really love single line comments. In the RFC to get rid of multi-line comments, it was brought up that single line comments are a pile of hot garbage for accessibility.

I think that there are too many corner cases, style preferences, and accessibility concerns for something like One Trust Rustfmt to come into being.

@nikomatsakis I think it's a good point that whether or not decisions are configurable may impact various style decisions along the way in rustfmt, and I'm very much in favor of explicitly stating in this RFC whether this is a supported operation or not.

My personal feeling here is the same as @wycats's, which is that rustfmt should not support configuration by default. Having a somewhat nonstandard method to have non-default configuration seems fine to me, but the eventual rustfmt executable we ship with the main distribution would not have these configuration options (but perhaps rustup would make a configuration-enabled rustfmt trivial to install).

To me the purpose of code is to be read by humans. Not written quickly or to be read by compilers, but purely to inform any future wanderer what was happening in my head when I wrote that chunk of code. With that in mind to me it follows pretty quickly that we want one standard style throughout the entire ecosystem if possible, as it's the only way that an arbitrary future wanderer will be able to understand anything I wrote years ago.

Some of the benefits of having a unified style I think are:

• Moving across projects in the ecosystem is a breeze as there's just no barrier to entry at all along the lines of reading code.
• Reviewing PRs is also a breeze as you'll never again have to request for different formatting or try to decipher various ways that code is written.
• Once you configure your editor to edit Rust code well, you can work with the entire ecosystem. I've personally had major problems where I consistently use 80-space line limits and have terrible readability in 100-space projects, this has literally deterred me from contributing to projects in the past. Having one style would erase this and once you can work with Rust code at all you can work everywhere.
• Projects which like to vendor code have consistent style, even for the vendored code. I've heard horror stories in Gecko here where the style is crazily different when you cross code bases.
• I personally have always found that I adapt inevitably to any style. This is pretty subjective, but I've heard a similar story from basically anyone I've ever talked to. No matter how much I originally dislike an idiom it'll eventually grow on me (especially if it's vetted by so many others).

To me though this is just all a lot of fluff around saying I'll never have to worry about style in Rust ever again. That's just another point in how Rust streamlines my development and makes it easier, not only in my own projects but across the entire ecosystem.

I'm also pretty confident that we can all surely reach a reasonable consensus on the style to move forward with rustfmt. The RFC process is actually really good at this in terms of building consensus, and we have lots of experience with it. If we choose a stylistic option that you might disagree with, it's guaranteed that there are very clear reasons why it was chosen despite other arguments in favor. We'll of course not make everyone the happiest as style is so subjective, but I know I'm at least much more comfortable if my own personal style wasn't overturned by fiat but rather carefully explained as to why it wasn't chosen.

Many Rust developers really love single line comments. In the RFC to get rid of multi-line comments, it was brought up that single line comments are a pile of hot garbage for accessibility.

For what it's worth, I strongly believe that a conversation about single-line comments that emphasized the impact on accessibility would find consensus for a default style that would work well for the widest group of Rust developers.

Making rustfmt configurable from this perspective simply makes the needs of people with accessibility needs second-class, which works poorly for open source projects. Since screen readers work poorly with single-line comments, that's something we should absolutely consider, without the cop-out of "just let people with screen readers have their own config." (again, that doesn't work for open source projects)

I also want to add that while it's easy for this conversation to become a very abstract discussion about high-level values, the discussion is focused on a very narrow question:

To configure rustfmt via rustfmt.toml, do you add the following to your Cargo.toml:

[dev-dependencies]

rustfmt-config = "1.0.0"

I can understand arguments that this might be unnecessary, but it's a narrow enough question that it doesn't seem like it needs to provoke a conflict over the value of expression writ large.

Working on a longer comment, but clarity about this would help:

To configure rustfmt via rustfmt.toml, do you add the following to your Cargo.toml:

I don't understand what advantage this has other than to discourage people from configuring rustfmt, which is what makes this seem to me like a value judgment. What is the advantage of this?

@withoutboats I feel like @alexcrichton's comment states the advantages pretty clearly. I'm confused why you're still asking what they are.

@solson Can you quote the part of @alexcrichton's comment you're referring to? Alex makes a strong case that people should not configure rustfmt, but this is the question about which we have a disagreement of high-level values. I am asking about what advantage there is to adding a barrier to configuring rustfmt other than to communicate to users that they should not configure rustfmt. If the only goal is to make a value judgment about what users should do, then this is a conversation about high level values.

If the only goal is to make a value judgment about what users should do, then this is a conversation about high level values.

I agree fully that this is a discussion about values, but not every values debate needs to have a zero-sum outcome. I'm suggesting that the exact tradeoff here (clearly discourage rustfmt config, but make it relatively easy to opt out) is a good balance of the two conflicting values, and one that both sides should be willing to live with.

@withoutboats Ah, sorry, I see what point you're driving at now. I agree that making it harder to configure rustfmt is nothing more than a signal to make fewer people choose to use non-standard formatting, but I think that's worthwhile so that we can achieve greater ecosystem-wide consistency and the advantages that come with that.

I would propose this policy: that rustfmt has no opinion about whether or not you configure it, but assumes that most users will not. Requiring users to download a separate dependency to use a configuration file doesn't pass this policy, because it makes using the tool more difficult for the minority of people who want to configure their styles without providing any benefit to the majority who use the standard format.

Some of the comments by others suggest a different understanding of what 'configuring rustfmt' would look like from the one I have - I have been assuming we're talking about a config file that resides in the crate root, and configuration on a crate-by-crate basis. If there is no config file in the crate root, the default formatting is used (rather than - say - falling back to a config in the user's home directory). This design seems sensible and consistent with the policy I just proposed - for people who want their projects to follow a non-standard config, they have to set that up with each new crate, but it is justified by how much easier it makes using the standard format for most users (since contributors never need to 'tweak' their configs when moving between projects).

Is this different from what other people have been assuming "configurability" means? What specific behavior are we disagreeing about?

@alexcrichton and @solson both bring up the role of a consistent format in making other peoples' projects more readable. This was surprising to me; I have not found code less readable in the different styles that I see floating around the Rust community, even though they differ from mine.

I want to understand if we just have different subjective experiences, or if I'm not considering an aspect of formatting. Here are the sorts of things I've noticed that are different from my own style, but which have not impacted readability for me:

• Indent width
• Whether you put the brace on a newline if the function has a multi-line where clause or on the last line of the where clause
• Whether multi-line arguments are indented once from the function, or aligned with the first argument
• Whether you align matchrockets or not
• Doc comments above the method, or inside the method with a !

Do we just differ on how much these impact our experience reading code, or are we talking about different kinds of formatting?

In contrast to the things I've listed above, I think things like "types are CamelCase, variables are snake_case, constants are SHOUTING_CASE` are important for readability because they provide semantic information, and I'm glad they're assured by lints.

To contrast with a third kind of guideline, style guides sometimes take positions on which kinds of expressions are allowed, on the basis of some consensus that certain expressions are confusing. rubocop, for example, will complain if you chain methods on multi-line blocks, which I don't find confusing at all. I wouldn't want rustfmt to police these because they actually impact what algorithms I can write; I don't think machines can determine if a particular algorithm is "clean code."

Reviewing PRs is also a breeze as you'll never again have to request for different formatting or try to decipher various ways that code is written.

Setting aside the readability question, it seems to me like the solution here is to run rustfmt on a githook or, even better, by bors. You'll still have to ask users who don't run rustfmt to run rustfmt otherwise, and this doesn't change if your project has a config file or not.

I'm also pretty confident that we can all surely reach a reasonable consensus on the style to move forward with rustfmt.

I'm not as confident that everyone will be satisfied with the consensus, given how subjective and even immaterial many of the decisions are. For example, I will continue to manually format my code if it doesn't keep my matchrockets aligned, and the good reasons not to align them won't sway me.

However, I want to make a different counterargument here - I don't care how other people style their code. If we're all agreed that I can configure my formatter with transgressing against good practice, I don't feel compelled to argue about what should go in the style guide. However, if the way to get my code styled the way I like is to convince everyone that my style is the way they should style their code, I am incentivized to participate in the bikeshed. Since this incentive structure is true for everyone, it has the effect of making the conversation more protracted and contentious.

EDIT: To be completely clear, I believe config decisions should be made at the level of a project, not at the level of either a user or a language community; if I'm contributing to rustc rustfmt should use the style rustc has designated, not whatever style I personally prefer, but when I start a project, it shouldn't throw up artificial barriers to me styling that project differently.

I've also bolded the parts of my comment that are requests for more information.

I will continue to manually format my code if it doesn't keep my matchrockets aligned

@withoutboats So, earlier on you mentioned "Whether you align matchrockets or not" doesn't really affect readability for you, and I don't understand why you would then insist on doing it a certain way.

I agree that most of the formatting minutiae make almost no difference in day-to-day readability. They only really make a difference when their formatting is new to me, where they can stick out and distract. That's why I find it more rational to decide not to worry about making sure the minutiae go my way and to aim for settling on a universal formatting with some things I don't like in it.

In my experience it's easy to get used to almost any style over time. But it's not that easy to get used to a ton of different styles all the time. It's way more valuable to me to have an ecosystem-wide consistent style than to use my own personally bikeshedded style in my own projects. I have a lot of bad experiences dealing with wacky customized C++ formats in different projects. Using languages where there is a single style followed by almost all projects is more enjoyable.

(More on the subjective experience of getting used to different styles... my mind gets mildly distracted by seeing the formatting rather than the code, if you know what I mean. It's like how novice Lisp users see parens and expert Lisp users don't, really. With inconsistent style it's like I'm always a slightly novice reader.)

@wycats

clearly discourage rustfmt config, but make it relatively easy to opt out

Does the need to opt-out really stop anyone? It's just more of irritating cruft when setting up the environment, as it often happens with overly opinionated software.

@withoutboats So, earlier on you mentioned "Whether you align matchrockets or not" doesn't really affect readability for you, and I don't understand why you would then insist on doing it a certain way.

Pure aesthetics, nothing else. Sorry if this seems like an unreasonable position 😦.

The only experience that stands out to me as similar to what you've described is some C source I read that indented every other block*, which was very unpleasant. Is your problem primarily with these sort of stylistic extremes, or do even small variations in style confound you? I think the config options rustfmt supports should be limited to config options we agree could have been a reasonable standard style, even though they aren't.

• I mean something like this:

fn main() {
    if foo.bar() {
    let baz = foo.baz(quux);
    if baz < quux {
        if baz.baz() {
        return 0
        } else {
        return baz
        }
    } else {
        return quux
    }
    } else {
    return 0
    }
}

@withoutboats Yeah, I guess from my perspective pure aesthetics is a wrong-minded approach to this issue. What matters for most development is widespread consistency. It's so pleasant to work in an ecosystem where people barely even think about style because it's just decided. And I still feel like having a single style is a lot more important than which particular style choices are picked.

But with @petrochenkov's point in mind, I actually don't think making rustfmt harder to configure will necessarily help. It's kind of a tricky social problem, I guess. If lots of Rust users reject the idea of compromising their personal preferences for consistency (like I want to), then it's somewhat moot.

But if most people can get on board with that concept, then I think there's something to be gained.

While I agree that there is a lot to be gained in having a shared, community-standard format (in terms of reducing friction and cognitive overhead), my feeling has been that defaults are enough to achieve that goal, especially if those defaults are arrived at via a consensus process like the one proposed here.

In particular, not only will the tooling default to that style, but it will be the required style for all rust-lang organization code, as well as the style used in the book and other core documentation. I imagine that all of these will have a big influence on the style that newcomers adopt.

And on the other hand, I don't see the proposed speedbump (requiring an extra line in Cargo.toml) to be all that different from the fact that you already have to add an extra file for configuration in the first place. I suppose it maybe adds a small layer of "you're doing something unusual", which might give people some pause -- or might just be an irritation.

I'm also not convinced that this question influences the design of the format; as long as you can set the options, everyone is free to choose and enforce their own personal style. People should participate to the extent that they want to influence the community standard, which will (I believe) determine the style for the vast majority of Rust code in the future.

And on the other hand, I don't see the proposed speedbump (requiring an extra line in Cargo.toml) to be all that different from the fact that you already have to add an extra file for configuration in the first place. I suppose it maybe adds a small layer of "you're doing something unusual", which might give people some pause -- or might just be an irritation.

The risk of the two possible outcomes are not symmetric:

• On the one hand, if we start by requiring an extra line in Cargo.toml and find that it doesn't really affect the rate of configuration and is widely perceived as an annoyance, we can easily include the configurability by default.
• On the other hand, if we start by allowing configuration and find that it's used more often than we expect, it will be very difficult (or even impossible without a major version bump) to remove it.

I think that argues for a more conservative approach, where people can opt into configurability in a way that doesn't impact our compatibility requirements, and keep an eye on whether it makes sense to enable the configurability by default once we have more experience.

Yeah, I guess from my perspective pure aesthetics is a wrong-minded approach to this issue. What matters for most development is widespread consistency. It's so pleasant to work in an ecosystem where people barely even think about style because it's just decided. And I still feel like having a single style is a lot more important than which particular style choices are picked.

I would only set a small number of configuration flags for rustfmt, but if I can't set these flags I won't use the tool in my projects, and style choices I care less about will, as a result, probably be inconsistent with the style chosen by rustfmt - by supporting configuration, rustfmt brings the code of people like me closer to the standard, while also being useful to me.

On the other hand, if we start by allowing configuration and find that it's used more often than we expect, it will be very difficult (or even impossible without a major version bump) to remove it.

This logic is very confusing to me. If configuration is used more than anticipated, that means a large portion of users prefer the configurable approach, and you should not remove this feature!

I would only set a small number of configuration flags for rustfmt, but if I can't set these flags I won't use the tool in my projects, ...

Are you saying that you wouldn't use rustfmt-config via your Cargo.toml because you don't believe the configurability should be factored that way? Or that you would use it, and believe that it would be so common in practice that the extra factoring would simply serve as an annoyance?

If it's the latter, I think my argument about the asymmetry of the two initial approaches is relevant. I'd certainly change my position if that prediction came true, and even advocate for a change in policy once we know the empirical results of shipping the first version.

This logic is very confusing to me. If configuration is used more than anticipated, that means a large portion of users prefer the configurable approach, and you should not remove this feature!

That's what I meant. If the configuration is used more than anticipated, we should make configurability the default, without requiring the additional opt-in via Cargo.toml.

The "inverse risk" is this prediction: making the configurability "on by default" will cause teams to use it more often, even if the majority of the team doesn't want to configure. In other words, I predict that the added Cargo.toml opt-in will give majorities on teams who prefer the default style a stronger position from which to argue against taking the time to establish an in-house style.

If we started with the config-available-by-default approach, and teams report that a clear statement by the Rust project through the added opt-in would benefit them in practice, it would then be very difficult to go back to no-config-by-default.

The inverse risk is that configuration is so common in practice, even with the speed-bump, that the speed-bump empirically doesn't succeed at its goal. But the resolution in that case is quite simple: remove the speed bump. I would personally advocate for that resolution if we saw that configuration was empirically very common even in light of the extra opt-in, so you don't need to worry that the "winners" here will become intransigent against the values you care about. I'm very willing to be persuaded about this empirical question by real-world usage.

@withoutboats

This logic is very confusing to me. If configuration is used more than anticipated, that means a large portion of users prefer the configurable approach, and you should not remove this feature!

That's because you don't understand the principles of opinionated software. It doesn't matter what users want or need, what matters is the Greater Good, as it's seen by the software's author.

EDIT:
@solson

That's an uncharitable view of the argument and an unhelpful way to participate in the discussion.

Yeah, sorry, I'm just allergic to this kind of discussions, nevermind.

@petrochenkov That's an uncharitable view of the argument and an unhelpful way to participate in the discussion.

That's because you don't understand the principles of opinionated software.

It sounds like your assumption about "opinionated software" doesn't match what I was proposing. Can you elaborate more on what you consider the principles of "opinionated software" and what you think the risks are?

@withoutboats I see, so you're banking on your personal style being within a certain number of style changes ("stylistic distance") from the default style and in that case you'd like the tool to bridge that gap. On reflection, that's quite reasonable, since it's better to have auto-formatted slightly-different code than non-tool-supported slightly-different code.

And some people will stick to much different styles no matter what happens, but you can't really do anything about that. Aside from repeatedly trying to convince them that consistency is better than customization the old-fashioned way. 😛

That's what I meant. If the configuration is used more than anticipated, we should make configurability the default, without requiring the additional opt-in via Cargo.toml.

I think the thread has been lost here - you said "if we start by allowing configuration and find that it's used more often than we expect, it will be [difficult] to remove it." If more users using configuration when its opt-in would cause us to make it turned on by default, why would more users using configuration when its on by default cause us to make it opt-in?

This is what is so confusing to me - there seems to be no downside to putting configuration in the main branch. It feels like you want rustfmt to force me to jump through a hoop because you don't like how I intend to use it.

I think the thread has been lost here

I tried to clarify in a follow-up. Did I not succeed?

Specifically, this comment: #1607 (comment)

Yeah, sorry, I'm just allergic to this kind of discussions, nevermind.

For what it's worth, I think there's a confusion about "opinionated software" that is probably derived from the way in which some communities have communicated the value. I think it's a good idea for us to work through what people who believe in some version of that value believe, without assuming that it means the same thing as the people who use vulgar language and try to shut down debate.

(EDIT: I'm responding to a now-deleted comment)

This comment thread isn't the right place to work out which particular style choices should be default, though. Hold those thoughts for the fmt-rfcs process this RFC proposes.

@ubsan I agree with you and @solson 😃

@withoutboats I see, so you're banking on your personal style being within a certain number of style changes ("stylistic distance") from the default style and in that case you'd like the tool to bridge that gap. On reflection, that's quite reasonable, since it's better to have auto-formatted slightly-different code than non-tool-supported slightly-different code.

My personal style requirements are:

• Spaces, not tabs
• Matchrockets are aligned
• When where clauses go over multiple lines, I want the type variables aligned, one to a line.

My belief is that a lot of people are like me - they have a small number of 'pet style issues' that they want to keep, whatever the style guide says, but otherwise they don't care that much. I think a configurable rust fmt will keep everyone in this camp consistent with the official style on the questions they don't care about (e.g. how function arguments are formatted or space count, for me).

I tried to clarify in a follow-up. Did I not succeed?

I don't understand why we would ever want to remove this feature from the default rust fmt build, once it was included. What do you think is the harm of having it in? If its in an alternative build, its still getting support.

@withoutboats

I would propose this policy: that rustfmt has no opinion about whether or not you configure it, but assumes that most users will not.

Reflecting a bit more, I think this is really the essential issue. Are we, as a community, taking the stance that you "should" use the defaults, or not?

To me, this RFC is only worthwhile if the result is a set of defaults that are recommended for use in all Rust projects. Otherwise, why go through the costly process of trying to build up a community-wide consensus about those defaults?

Put differently, the question is whether rustfmt is a tool for encouraging consistency across the ecosystem (thus easing moving between projects, reducing arguments about style, etc), or "merely" a handy tool for auto-formatting code in the style you prefer. Again, I think this RFC only makes sense if we, as a community, are aiming for the former.

And I think it's worthwhile to do so. Similarly to the way that Cargo standardizes workflows across the entire ecosystem, standardizing formatting reduces friction when moving across projects or when starting new ones. One less barrier to learning and using Rust.

(All that said, I continue to think that if we reach consensus on the above -- which to me is key to accepting this RFC -- then that consensus and the defaults alone are enough to nudge people toward the standard format.)

@aturon

Put differently, the question is whether rustfmt is a tool for encouraging consistency across the ecosystem (thus easing moving between projects, reducing arguments about style, etc), or "merely" a handy tool for auto-formatting code in the style you prefer.

Defaults and documentation should encourage consistency across the ecosystem, not the tool itself.
Suppose I need to tweak formatting because it needs to match pre-existing C++ code formatting in a mixed-language project, or it needs to match a local style guide, or just because defaults are especially ugly in some aspect, in this case abstract community values is the last thing I care about, the task at hand is more important and the need to jump through the hoops to perform the task is perceived as a spoke in the wheel, not a friendly advice.
You mentioned Cargo, and it's exactly an example of a software that behaves this way, it's good and novice friendly when it's used in isolated and Rust-centered environment, but turns into a horror, when it needs to be integrated into all kinds of silly but unchangeable pre-existing workflows and infrastructures.
(EDIT: This is also an answer to @wycats )

but turns into a horror, when it needs to be integrated into all kinds of silly but unchangeable pre-existing workflows and infrastructures.

Can you given an example or two of this? We're familiar with a number of integration problems (thanks to a number of integration efforts) and have been steadily working to eliminate them.

That said, it doesn't sound like "I need to integrate Rust into a bespoke environment, I'll need to add rustfmt-config to my Cargo.toml" would turn the tool into a horror?

@wycats

We're familiar with a number of integration problems (thanks to a number of integration efforts) and have been steadily working to eliminate them.

That's nice to hear. rust-lang/cargo#1180, rust-lang/cargo#1106, rust-lang/cargo#2063 (comment) (regarding VCSs in general).
To be fair, I haven't dealt with Cargo myself for long time, so things could change to the better.

"I'll need to add rustfmt-config to my Cargo.toml" would turn the tool into a horror?

Not a horror in this case, just a pebble in the shoe, spider under the shirt, [insert any other metaphor for a small irritating thing]. What I dislike is the attitude for deliberately making things worse.

Hey, you have given me too many knobs!

First, I must say that I don't have a really strong opinion in terms of @nrc's proposal per se. Keeping the style RFCs in the "main" vs. separate RFC repos has both pros and cons. I do feel though, that there may be people who are more interested in "style RFCs" than others, and the advantage of moving those discussions to a separate repo means that it's easier for people to filter out stuff that they may not care so much about. So if the team can manage the extra administrative burden etc, I'm kind of pro the idea.

Regarding "to configure or not configure, that is the question": I think it depends.

(TL;DR at the very end of this)

Do we want Rust to become a language where everyone is expected to think alike in terms of style preferences? Or do we understand and accept that there is room for diversity, even in terms of style choices?

My POV would be that we should aim for making Rust be a full-fledged replacement for C and C++, that eventually it would be used in more new projects being written than C and C++. That is of course an extremely ambitious goal, and there's a lot of work until we're even anywhere near there. But I think it's important to know what we are aiming for here.

With that as the target, can we really expect that all projects using Rust in that future scenario would be so aligned in terms of style preferences that they would accept the "Rust style"? Is that at all realistic?

I personally don't think it is, because there are very valid reasons why one would want to tweak settings. One good example is the line length (which brought me here in the first place, actually... 😆). If the default of rustfmt would be 80 characters for example, I would definitely tweak it. All code I'm currently writing (in Ruby) uses a maximum line length of 132. If me and the other people I'm working in our projects are comfortable with that, and we feel it's a reasonable setting, why would we suddenly want to start limiting our lines to a much shorter length just because we are adopting Rust?

Another example: the Rust style guide suggests the use of trailing commas. It's something I personally find a pretty strange choice, and I actually read this (#273( and this (#290 thread the other night. I think both sides in the argument are reasonable. I personally have my preference, but I know other reasonable people like @steveklabnik have a different opinion. Letting the tool help either side of arguments like this "bang the head" on the other ones is really not that helpful. "Our way is the default, and you have to jump through hoops if you want to be obnoxious enough to be different". Yes, I know I'm exaggerating quite a bit here (and to put it clearly, I am not saying that anyone in this thread has said that), but it's to prove the point that this is the kind of message we would be sending out if we go with the "don't be configurable by default" approach.

(Please don't start a long debate about these specific style details - the point here is not to prove either side's point, just to give some examples of style choices where differences can be warranted.)

A reasonable programming language and tool (rustfmt in this case) should, IMHO, make reasonable choices when it comes to these things. I am a big fan of Rubocop and the Ruby Style Guide when it comes to these things. Rubocop is, as some of you may know, very configurable. It doesn't try to "enforce" its world view upon you; it will even help you to display the names of the specific settings that you are breaking so you can easily:

1) Read about it to find out more about the possible settings for it, or
2) Disable it, if none of the tool-provided options works for you.

I find this a very pragmatic and sound approach, to be honest. Of course it means that Ruby projects using Rubocop can diverge a bit in terms of style choices, but you know what the good part about it is? That these choices are documented. In the .rubocop.yml file. I cannot really see that these design choices have been harmful to the Ruby community.

I think the worst thing that could happen in our case is that we make a great new tool (rustfmt) that is overly stubborn regarding things like this, to the point where potential users would dislike it so much that they don't even want to use it. Clearly, I don't think we can allow that to happen.

And finally, before the conclusion, I think that not all style settings are of equal importance. Line length is a good example; it is, in my opinion, of less importance than e.g. braces placement and whitespace/not whitespace questions (since these have a larger overall effect on the code). So I feel that in some areas, it's more important to reach a consensus than in others.

TL;DR: I think the point @aturon made is really the most reasonable approach:

While I agree that there is a lot to be gained in having a shared, community-standard format (in terms of reducing friction and cognitive overhead), my feeling has been that defaults are enough to achieve that goal, especially if those defaults are arrived at via a consensus process like the one proposed here.

We have such a good language in many other ways; I don't think we should take too hard a stance on this matter since it clouds the other project goals. In other words, I suggest we go with the "leading by example" approach rather than "punish people who can only agree with the defaults to 97%".

Do we want Rust to become a language where everyone is expected to think alike in terms of style preferences? Or do we understand and accept that there is room for diversity, even in terms of style choices?

I feel like this paragraph misrepresents the arguments. The goal of the consistency argument is to save time by having people not think about style at all. And be careful not to mix up style diversity and other kinds of diversity. Style diversity is a net loss for the ecosystem. I accept that some people feel strongly about needing configurability, and I've been convinced that's fine, but they should be conscious of the downside.

Letting the tool help either side of arguments like this "bang the head" on the other ones is really not that helpful. "Our way is the default, and you have to jump through hoops if you want to be obnoxious enough to be different".

Eh, I disagree (even with the exaggeration in mind). If my favoured style choice doesn't become the default, I would feel strongly that I should accept the default because having my exact style really doesn't matter compared to the benefits of ecosystem consistency. I would encourage anyone who cares about the latter to treat it the same way.

That these choices are documented. In the .rubocop.yml file.

I think this ties in well with @withoutboats's arguments (which already convinced me a little bit of configurability is ok). It would be worse to have non-rustfmt'd projects than slightly-configured (and thus documented) projects.

not all style settings are of equal importance

Agreed. I can accept people tweaking minor things. I'd be slightly more annoyed if people tweaked more important things, and I would avoid doing it myself, but that's a social issue that we can't effectively solve via making rustfmt harder to configure, IMHO.

TL;DR: I think I agree with your conclusion but not some of your arguments.

I feel like this paragraph misrepresents the arguments.

Yeah, you're right - My apologies to anyone that might have taken it the wrong way.

The goal of the consistency argument is to save time by having people not think about style at all. And be careful not to mix up style diversity and other kinds of diversity. Style diversity is a net loss for the ecosystem. I accept that some people feel strongly about needing configurability, and I've been convinced that's fine, but they should be conscious of the downside.

To me, that's a somewhat inadequate way to express how it really works. Just by having an unconfigurable/hard-to-configure tool (and strong "community recommendations") won't make me think less about style. People are different, and I can only relate to myself in this case, but I definitely care & think about style (probably more than quite a few people). So if the tool would make choices that I don't agree with, I think I would:

• for some of them, accept that a different viewpoint than my own is reasonable and go with the default (= ecosystem win)
• for some of them, be annoyed that the default is wrong but accept it (= ecosystem win)
• for some of them, be annoyed to the point where I would either bend the tool, or manually tweak the result of the tool (= ecosystem loss).

I do agree strongly that it's good if the ecosystem supports a good, community-based "style recommendation", and the more closely people follow this style recommendation, the better. I can even go as far as to say that it's admirable that people have been thinking hard on how to achieve this (by disabling/complicating configurability). Still, I think my main point is this: We will never get to the point where 100% of the people will accept 100% of the style guide. (and like you say, noone has claimed this, but it's still an important point to emphasize because it affects the view on configurability)

Because of this fundamental principle, I find it's best to focus on, to put our energy on the 80, 90, 97% (or whatever the percentage is) where we can actually find a more-or-less community consensus, and try to make as many projects as possible use these settings. The remaining % of the settings - it's really not worth the effort to try and make everyone use the default here, so let's just live with and accept that people will tweak these (less important) flags. Of course, the greater the "common ground" is, the better.

Now, the really interesting question is of course: which options are less important and which ones are more important. 😉 But let's postpone that discussion until later, when we (hopefully) have the suggested RFC process in place.

I find it's best to focus on, to put our energy on the 80, 90, 97% (or whatever the percentage is) where we can actually find a more-or-less community consensus, and try to make as many projects as possible use these settings.

Agreed. Maximizing the common ground via style RFCs and encouraging people to keep an open mind on style issues (which makes them overlap more with the common ground) seem like the most effective ways forward for ecosystem consistency.

Should it be possible to enable report_todo and report_fixme without changing cargo.toml? These two options do not change the formatting. (Apart from that I don't have strong opinions regarding the RFC)

There are a lot of good reasons for promoting style consistency in the ecosystem. Having a consistent experience is always nice; it reduces barriers to entry, makes it easier for people to review and contribute to code in different projects, reduces friction, and so on.

It is good to push back on trying to be an all-configurable tool for all people. While I love Emacs, I hate the fact that I have to either spend a lot of time setting up a shared Emacs config that works across platforms so I can share one configuration between several different machines, or do a bunch of manual configuration on each machine to bring it up to what I consider a reasonable baseline state. Or as an example that may be closer, it's always frustrating having to set up every new Git repository with a boilerplate gitignore, and having Git beginners forget to do so and so check in a lot of stuff they didn't mean to. There is significant value in getting the defaults right up front, so that you don't have unnecessary divergence, lots of poorly configured projects, make it hard for beginners to get up to speed, and so on.

That said, I think that the reasons for allowing some configurability outweigh those to disallow it entirely. I think that there will always be some cases in which people need to opt out of some of the formatting decisions. It may be projects that have to interoperate with other software and follow their conventions; perhaps long naming conventions mean that you need to increase the maximum width, or a convention of long argument lists mean that the convention is to always wrap function argument lists one per line, or the like. Or there are the accessibility concerns brought up earlier; there seems to be an overwhelming community preference and historical precedent for single line comments, but there are some people who would really prefer to use multiline comments for code that they maintain due to accessibility issues.

Another that I don't think has been brought up yet is that because rustfmt was not available as of Rust 1.0, there has already been some divergence of style between different projects. There does seem to be a fairly strong community consensus on the basic formatting principles, its nowhere near as bad as the K&R vs GNU vs Linux kernel vs BSD conventions in the C world, but there are different styles out there. Introducing an unconfigurable rustfmt would mean that a lot of people would have to either opt-out of using it, or accept large formatting-related patches to catch up with the style decided on, which can lead to a lot of churn in a codebase that causes other forms of pain. Sometimes rustfmt can be buggy and delete code (hopefully by 1.0 it won't, but I've seen it happen when trying it before). But even without bugs like that, big global reformattings generally conflict with most outstanding branches, making merging and rebasing more of a pain; and sometimes either automatic or manual merges go wrong, introducing real bugs. If there are sufficient configuration options to reduce the size of the diffs, it can be easier to get started using rustfmt, and move gradually and incrementally to a common style, or stick with something that only diverges a little and so get the benefit of a common community wide style other than a few small cases.

I don't believe Go had this problem, because gofmt was introduced along with 1.0, but given that Rust 1.0 has been out for over a year, and it may be closer to two years by the time all of these RFCs are decided upon, implemented, and rustfmt 1.0 can be released, that's a lot of code that has had time to diverge.

What, then, about hiding config options behind a speedbump? I don't really see the value to this. Having to configure options at all is already a considerable speedbump; to get there, you have generally already tried out rustfmt on your code, taken a look at the result, decided you didn't like it, took a look at the help, tried to figure out if any of the options were relevant to fixing your issue, tried again with those options, compared the diff again, and so on.

Adding yet another step where you have to figure out that you need an extra crate entirely is like adding salt on the wound; even worse if this happens when working on a long plane flight without an internet connection, because perhaps you've been working happily with rustfmt defaults as part of your workflow, until you write something more complex that hits a bad case for you. I have recently been bitten by cargo not working when on a long plane flight over the Pacific without internet access available; the "what if you're on a long plane flight" is not a theoretical argument.

All that said, we should strive as hard as possible to make configuration unnecessary. Much better than adding speedbumps would be to make the formatting conventions work in the vast majority of cases, so that people only use them if they really need to for one of the reasons mentioned above, or for minor aesthetic differences (80-column limit, lined up matchrockets, etc) that don't substantially affect readability of the code.

And even with a few small differences in configuration between different projects, standardization across the ecosystem would be significantly better than if some projects opt in to using rustfmt, and some opt out because for whatever reason they just can't work with some formatting decision that has been made. With rustfmt.toml checked into the repo, no matter what the particular options that have been decided on are, the community wide standard can still be "run rustfmt before committing, and we'll have bors/travis/some bot check that PRs are rustfmt clean", and it will just pick up the defaults for that particular project.

The RFC process is very important for coming up with a set of formatting conventions that we can get consensus about, so that rather than adding speed bumps to discourage bad behavior, we instead add nice flat unobstructed pavement in the direction we do want people to move in.

The one speedbump that might be valuable would be to have a stabilization process for rustfmt config options; just like with features in the language, it can be good to get some experience with whether particular pieces of configuration are valuable before deciding to support them forever. Once the RFC process dust settles and 1.0 is around the corner, it may turn out that some of the options are not needed by anyone, or at least not pulling their weight. It might be worthwhile hiding them behind some kind of gate, maybe behind cargo features, and then removing those via RFC one or a few related options at a time, so people can make arguments about why it's worth stabilizing them, or if no one actually needs them, they can eventually be removed.

@lambda Thanks for the great writeup! This is pretty much exactly how I feel on this particular question as well.

Ah, I had expected the config or no config question would be the first one to be tackled by the new team, rather than here. But seeing as we're doing it here, here are my thoughts:

• No config has been very successful for Go, but Rust is a very different language and a very different community.
• If we don't make rustfmt configurable, someone will fork it to make a configurable version.
• I believe there is great benefit in consistent formatting. Furthermore, I think there is even more benefit in very consistent formatting, that is, if 90% of the community use the same style that has an order of magnitude more benefits than if 45% of the community use the same style, not just double. Therefore, we must do as much as possible to encourage users to use the defaults.
• Using consistent style is a benefit to others, rather than to yourself. You suck up some pain in not having exactly the style you prefer for the benefit of making your code easier to read for others. To me, this implies that we must use a degree of 'stick' as well as 'carrot' to encourage people to adopt the defaults 'for the greater good'.
• There is a spectrum of options between free configurability and no configurability. And we are picking a point on the spectrum - I don't think either extreme is a good point.
• Even once we pick a point, the style team will need to make decisions not just about the default, but about which options should be exposed (and in which ways).

My proposal is that we follow the nightly/stable model and stable rustfmt (distributed with Rust, easiest to find on the webpage, etc.) does not allow configuration, but nightly rustfmt (available on the webpage, but less prominently, or buildable from source, probably distributed with nightly Rust, but not sure about that) allows configuration in the current manner. This could be easily implemented with a build flag.

We could also allow a handful of configuration options on stable, and all options on nightly. This might be useful for minor things which don't affect readability too much and where there isn't an objectively better solution (aligned match rockets are a good example from this thread).

One thing that has come up from a few people is the idea of having an overarching vision for the style guidelines, as opposed to each RFC being a sensible decision and the overall effect being terrible.

I have this in mind, but I don't think it is a problem. One advantage of having a dedicated team is that they can keep in mind the big picture in the same way that the current teams do. Furthermore, by insisting that proposed RFCs are accompanied by an implementation it should be easy to experiment and see how rules interact.

The core team is ready to move this RFC into final comment period 💬

By and large, there appears to be agreement on the mechanics proposed here. The main point of contention has been a question at the core of this effort: do we view the outcome of this process as a strongly-recommended set of defaults? The exact way that we "strongly recommend" the defaults is an important but ultimately secondary issue. To come to any consensus about the process, we need to know what kind of status we intend to give it.

In particular, if this process does inform a community-wide recommendation, then everyone who has strong stylistic preferences has incentive to participate; we should all want to arrive at a solution where we're not tempted to customize the rustfmt defaults for our own projects.

From my read of the excellent comment thread so far, it seems that most participants do think the outcome of this process should be a recommended set of defaults. However, most participants also think that communicating this recommendation by not providing knobs by default is a step too far.

During FCP, let's try to draw the above discussion to a conclusion (in particular, speak up if you disagree strongly with the above!) And of course, if you see other major concerns, now is the time to raise them.

However, most participants also think that communicating this recommendation by not providing knobs by default is a step too far.

@aturon: By "by default", do you mean "without the speed-bump" or "in rustfmt at all"?

@8573 I don't think anyone is currently arguing for never providing knobs in rustfmt (speak up if you are!). So yes, I was referring to the speedbump.

@aturon - I think you summed it up quite well there. No objections from my side.

The RFC still frames the strike team as a new subteam. I prefer not to set the precedent that 'strike teams' are subteams. I do want to empower people to make decisions, and to give them credit, but prefer not to create increasingly special-purpose teams. Can we remove the language making the strike team a subteam? For comparison, the unsafe strike team RFC does not establish a new subteam. Both of these are going to be setting precedent.

I also think it is desirable for strike team RFCs to lay out the conditions for concluding their work and disbanding, similar to charters for things like IETF work groups.

@brson I agree with the "strike teams are not subteams", but for a different reason. I think that the subteams should start to step down over the next ten years, and strike teams should start to take their place - specialized teams which can focus on a specific area, rather than the "lang team, responsible for designing new language features". This would bring our model more in line with modern C++, which is a language that's had a crazy transformation from C++03 to C++14 standardization processes, and whose standardization process works really well.

I don't agree strike teams should lay out the conditions for concluding their work, in other terms.

rustfmt seems pretty uninteresting to me if it's not a ticket to having my code formatted in a way that's acceptable to 100% of the rust community. there's formatters for all kinds of languages and most people totally ignore them and most lang communities never agree on configuring them, gofmt probably only works because you don't have to think about formatting politics.

future generations of rust programmers won't thank us if we fragment the community along formatting lines just to preserve the preferred style of present-day codebases

I'm sorry if this has already come up, I've only skimmed this thread, but I'd love to see a method to disable automatic formatting in certain places, something like #[cfg(no_formatting)].
Especially repetitive test code does often not benefit from formatting example.

@hoodie you can do that with the #[rustfmt_skip] attribute:

https://github.com/sfackler/rust-postgres/blob/282bf50e79964e76b9187c7512140ecb628127d9/src/lib.rs#L410

@brson it's unclear to me exactly what it means that a strike team is or is not a sub-team. I mean they are both teams of people working on a facet of Rust, they both have authority (thought not total authority in either case) to make decisions. Clearly a strike team should have limited scope in both time and jurisdiction, but that doesn't seem enough to explicitly say "is not".

As far as I see it, calling a strike team a (temporary) sub-team is a way to re-use the technical and social infrastructure we have in place, rather than having to recreate that infrastructure. If there are specific aspects of being a sub-team you think we'd be better not to emulate, then I think it makes sense to call them out, that seems preferable to starting from scratch with strike teams.

@nrc I'm warming up to the idea of lots of teams, some of them being temporary. I wouldn't mind adding an unsafe team and rustfmt team to teams.html, as long as their scope is clear, and as a project we're making this expansion intentionally, and the other RFC is aligned. It feels though like there are policy issues to be resolved about what it means to be a team that are larger than this RFC.

I've left some similar comments on the other RFC.

Whatever style you pick here, please don't use egyptian brackets. It just looks horrible everywhere.

@darkstalker This comment thread isn't the right place to work out which particular style choices should be default. Hold those thoughts for the fmt-rfcs process this RFC is proposing.

I feel compelled to add, "looks horrible" comments ought to be ignored. If you want to have a voice, at least bring something meaningful to the conversation.

I'm 👍 on the idea of having a strike team to work out the "default and recommended style" for Rust programs.

I am fine with rustfmt permitting knobs by default, but I think we should strongly encourage people not to use them. I suspect few people will anyhow, both because it would bring their code out of sync with the mainstream, and because it's just that much more annoying to have to set them up.

I do wonder: once we settle on a default style, I imagine there may be future questions that arise -- or corner cases that were not considered. Is there a plan for resolving those questions? Maybe this won't really be a big problem?

Could vertically align be considered? Many people love it.
https://shkspr.mobi/blog/2014/11/why-i-vertically-align-my-code-and-you-should-too/

Especially in the match block with one line branches.

This discussion isn't for defining the standards, just for defining the process by which we define the standards.

I would suggest opening an issue on rustfmt itself to make this an option first.

@aturon It seems that the conclusion to the 'should there be knobs' is unchanged, and a qualified 'yes'. I would suggest this should be clarified in one of the first style team RFCs. Another question that has been asked is 'what, precisely is the duration of the team and what happens after?' I suggest that the duration should be one year, and at the end of that time responsibility for style team issues should go the tools team, unless the core team decide otherwise at the time. The objective is that there should be a fairly complete set of style guidelines by then, and that these will be in maintenance mode after a year (I foresee changes being needed due to new language features and due to technical changes as Rustfmt evolves. I expect both could be managed by PRs to the style repo, shepherded by the tools team).

Are there other questions that need resolving here? If not and the above is acceptable, I can update the RFC.

Some thoughts:

• I don't think it's urgent to focus on formatting code, for now. (Just continue doing it for experimental.)
• Are there largely crates on crates.io have problems (bad styles) that hurt readability/cooperation? What will be solved?
• It's a shame to enforce people formatting their code in an arbitrary style.
• There are many natural controversies in code style, most subjective. e.g. 80-column limit or not, { at new line or not. It's hard to say which one is right, or which one is more readable.
• The community will never get consensus about that, unless there are dictators (we hate dictators).
• By unify code style in an authoritarian way, you solve little problems, and you get little gain. At the same time, you dissever the community. You finally get a unified style, since people who dislike the style have left the community.
• People have rights to format their code in a style they like, unless the style is 'wrong'. (So please focus on defining which style is wrong.)
• Some people from core team have proposed that, will not allow configuring format style by default. I worry about this. (And I claim here: I'll never use a format tool if it forbid configuration.)
• I don't think a 'default style' or 'recommended style' should be a style which force people to use.
• The default rustfmt tool SHOULD allow configuration.

Please read the final RfC decision. All the points you mention have been discussed before; the final comment period is not for rehashing resolved discussions.

It's a shame to enforce people formatting their code in an arbitrary style.

Nobody is doing that.

Some people from core team have proposed that, will not allow configuring format style by default. I worry about this.

This is not the final decision, if you read the thread. The decision is to have a "strongly recommended set of defaults". The usage of the word "defaults" implies that it is configurable.