Consider using enum_discrim_align_threshold = 20 and struct_field_align_threshold = 20 as the default.

[effinsky]

Compare the current default:

against the suggestion (with value 20 set after which to ignore):

Again default:

Again suggestion:

Formatting this way is the one thing I like about the Go base formatter. I think some Haskell formatters do the formatting that way too. Having discovered similar options on rustfmt I cannot help but want those as the default -- they may be a matter of preference, as so many things are, but I do find switching the options and aligning types / values vertically helps quickly parse the defs.

Would be swell to see that adopted more widely -- and it won't be unless it becomes the default in a tool as important to the Rust ecosystem as rustfmt. Again, something to consider. Thanks!

[calebcartwright]

Thanks for reaching out, but I'm going to close this for a few reasons.

The first and foremost of which is that the default is dictated by the official Rust Style Guide which very intentionally went in the current direction over the visual/vertical default styling you prefer. Rustfmt's config options you mentioned are simply Rustfmt opting to make it possible to achieve your preferred style in a non-default manner. That being said, we unequivocally cannot ever change the default of an option if doing so would break the formatting stability guarantee or fail to uphold the Style Guide (both of which would occur).

Although it's a bit moot given the above, the other reason I'll note is that while your issue was quite detailed (and that's always appreciated!) it doesn't actually propose anything concrete, as both options require a numerical value that currently defaults to zero.

Finally, if you really want to push for a different default in a future style edition, the better place to do so would probably be https://github.com/rust-lang/style-team.

However, this is a matter that was thoroughly discussed and has been settled for a long time, and there's not really much of an appetite to change defacto Rust style and typical behaviors/expectations of most Rust developers just to make Rust code look more like code in some other language X. As such just a warning/my .02 that any such proposal to change this is unlikely to prove fruitful.

[effinsky]

Had no idea there was a discussion on this on the style team -- could you please link to that? I had no idea this had the potential to be controversial. I thought it was a pretty easy pick. Naive me!

Regardless, I can see some folks using this here and there so maybe not all hope is lost. And it's not about making Rust look like another language. I'll say it's about making the code look clearer and more easily parsable -- and we couldn't so easily know this if it weren't for those other languages doing this well (imo). Nothing wrong with looking around for good examples.

[effinsky]

Seriously hope it at least becomes stable.

[calebcartwright]

No worries! Also apologies for my choice of wording as I knew you weren't trying to imply we should make Rust look like Go/Haskell just because those were preferable, but I see how my last comment may have implied that.

The tradeoffs of visual/vertical vs. block indent were discussed at length in various places as part of establishing some early principles and goals for the styling of the language.

In general you can find most of the prior discussion, options considered and associated reasoning through GitHub's standard search in https://github.com/rust-lang/style-team

Unfortunately I don't have the bandwidth to do a full traverse through all that history, but would suggest in particular starting with the two below issues to get more historical context on why Rust opted to go in a different direction:

rust-lang/style-team#8
rust-lang/style-team#4