Oh! In that case I have probably misjudged Rustfmt. My apologies. I was also overdramatizing with the "makes me sad" bit. :-)
I'm not an active Rust user, so probably won't be involved in the RFC process, but I'm glad to hear about it.
OTOH, even for a language I do actively use, I'm a bit reluctant to get involved in a formatting standards process. So many people seem to approach code formatting from a point of view of "This is how we've always done it, this is consistent with other previous standards, so this is how it should be." And then whoever gets the most agreement wins.
I don't often see discussions based on whether there may be actual engineering advantages to one formatting style vs. another. For example, I put spaces inside the parentheses in my function calls and expressions. Many see that as an arbitrary stylistic choice - and object vehemently to it! - but it actually ties in very closely to the column alignment vs. indentation choice in the examples above.
I talked about that in some detail in one of the comments I linked above, so won't belabor it further here. :-)
Maybe that's my beef with coding standards: they tend to take each style decision as an independent, fairly arbitrary choice, instead of listing the goals we're looking for and seeing how different style choices may work together to achieve them.
I don't think there's very much empirical evidence about the engineering advantages of different code style standards. Fortunately, Rust's approach will always be to establish a reasonable compromise and allow you to deviate for your projects (this is why rustfmt is designed to be configurable).
The idea is to pick a standard that people can use as a default, which becomes the "familiar Rust standard". It's mostly for folks who _don't_ care much about formatting nuances.
If you do have a style you prefer, you can always configure your rustfmt to follow that style.
I'm not an active Rust user, so probably won't be involved in the RFC process, but I'm glad to hear about it.
OTOH, even for a language I do actively use, I'm a bit reluctant to get involved in a formatting standards process. So many people seem to approach code formatting from a point of view of "This is how we've always done it, this is consistent with other previous standards, so this is how it should be." And then whoever gets the most agreement wins.
I don't often see discussions based on whether there may be actual engineering advantages to one formatting style vs. another. For example, I put spaces inside the parentheses in my function calls and expressions. Many see that as an arbitrary stylistic choice - and object vehemently to it! - but it actually ties in very closely to the column alignment vs. indentation choice in the examples above.
I talked about that in some detail in one of the comments I linked above, so won't belabor it further here. :-)
Maybe that's my beef with coding standards: they tend to take each style decision as an independent, fairly arbitrary choice, instead of listing the goals we're looking for and seeing how different style choices may work together to achieve them.