Your formatting style works too, and rustfmt will switch to it for function calls that exceed the line width limit.
rustfmt is not properly handling alignment in combination with hard tabs. It should either break after the open paren and indent both names, or break near the '+' and align them both.
My personal impression from these examples you gave is that line-breaking inside an arithmetic expression is generally a horrible idea. If you have something like
let result = (first_long_variable + second_long_variable) * (third_long_variable + fourth_long_variable);
My position is that the only way to make this look good under a line length limit is
let factor1 = first_long_variable + second_long_variable;
let factor2 = third_long_variable + fourth_long_variable;
let result = factor1 * factor2;
(where of course `factor1` and `factor2` would be given names that make sense in context)
Thinking about it, you're probably right. One thing you're missing for your comment is different field name lengths, which is important because you seem to care about alignment of field values:
field1: 1
this_is_a_longer_field: 2
Playing with rustfmt online [1], I found that by default it doesn't do that:
field1: 1
this_is_a_longer_field: 2
As a sibling comment says, you must have an option turned on an option for this, and your complaint is that this option isn't working for these nested structs. I guess that's the risk of not using the formatter in its default configuration. But I agree it probably is a bug.
(You've presumably also got an option turned on for tabs. I honestly think that is quite a niche preference nowadays - cue flame war - so I can see that there would be bugs in that option too. But although you bring up tabs in your comment here and in your blog post, I don't see that it's related to the bug you're talking about. Once the formatter has (incorrectly, you argue) decided to format those lines as "one more level of indentation than the line before", it chooses the correct combination of tabs and spaces to do that.)
> You've presumably also got an option turned on for
> tabs. I honestly think that is quite a niche
> preference nowadays
gofmt always indents with tabs, so I'd argue that it's not _that_ niche.
One might also argue that, as a zero-cost abstraction for consistently applying a developer's preferred indent depth, they are the most Rust-appropriate option </s>.
> Once the formatter has (incorrectly, you argue) decided
> to format those lines as "one more level of indentation
> than the line before", it chooses the correct
> combination of tabs and spaces to do that.)
I'm not sure that's the case. It seems to be correctly aligning it when using spaces, so I think the issue is that somewhere it gets confused about whether to indent or align. A lot of very old indenters will treat tabs and spaces as interchangeable, which is why you see so much poorly-formatted C in open-source UNIX tools.
> A lot of very old indenters will treat tabs and spaces as interchangeable, ….
Indeed. If you're going to align expressions in a file that uses tabs for indentation then you need to use tabs up to the block indentation level, but spaces after that for the alignment. That's the only way to ensure that the lines continue to be aligned for any tab-stop setting. Many editors will mangle this horribly, however, by replacing some or all of the spaces with tabs. If you're using tabs for indentation then you really need to turn on visible whitespace and also disable automatic conversion of spaces to tabs unless you're sure your editor is one of the few that gets it right.
rustfmt is not properly handling alignment in combination with hard tabs. It should either break after the open paren and indent both names, or break near the '+' and align them both.
Good output if aligned:
Good output if indented: Output of rustfmt: For the same expression to be half aligned and half indented is an error.