Alignment of let bindings

[wdanilo]

Hi!
I really like what rustfmt is doing, however, one thing hurts me strongly here. It allows the vertical alignment of struct fields, but does not allow for such alignment of let bindings. Consider the following code:

impl Scene {
    fn new() -> Result<Scene, Error> {
        let doc = document()?;
        let canvas = doc.get_element_by_id("canvas").ok_or(DOMError::missing("canvas"))?;
        let data = Rc::new(SceneData { canvas, context });
        let data_weak = Rc::downgrade(&data);
        ....
    }
}

I believe it is much nicer to read the following code:

impl Scene {
    fn new() -> Result<Scene, Error> {
        let doc       = document()?;
        let canvas    = doc.get_element_by_id("canvas").ok_or(DOMError::missing("canvas"))?;
        let data      = Rc::new(SceneData { canvas, context });
        let data_weak = Rc::downgrade(&data);
        ....
    }
}

Would it be possible to add some treshold option to rustfmt for such a style? :)

[johnnyutahh]

Checking in on this almost-1-year-old feature request:

1. what's the feasibility this gets implemented in the near(ish) future?
2. can anyone provide specific pointers on where/how I (or my team) can contribute (for this feature)? eg: the specific file/module location for suggested review+edits?

In any case, many thanks to all the project contributors, we significantly-appreciate their efforts.

[ @topecongiro @calebcartwright @scampi @wdanilo @rust-lang-owner ]

[calebcartwright]

@johnnyutahh thank you for the question and kind words!

1. what's the feasibility this gets implemented in the near(ish) future?

To be fully transparent, this is a really low priority for the rustfmt team. That doesn't mean we're opposed to potentially supporting this, it's just a matter of the limited resources/bandwidth and priorities.

Remember that rustfmt's primary purpose is to reformat code according to the Rust Style Guide, and the style support requested here is very divergent from the Style Guide. There's a lot of open bugs/feature requests/etc. (many of which have been open longer than this one) that are related to the Style Guide and/or have a lot more community demand, so those backlog items as well as the general work related to the ongoing maintenance and support of rustfmt take priority, and occupy the bulk of the limited bandwidth that we have.

We'd certainly be happy to take a look at and consider any community submitted PRs that implemented optional support for this type of style with a configuration option, but it's highly unlikely that we'll get to it ourselves. Given the strong divergence from the official code style, we'd also have to weigh the overhead added by the hypothetical code required to support this style.

2. can anyone provide specific pointers on where/how I (or my team) can contribute (for this feature)? eg: the specific file/module location for suggested review+edits?

The formatting logic that handles these local statement kinds can be found in src/formatting/items.rs. However I think there'd probably be a need to define the parameters a bit to account for all the potential use cases and scenarios (exceeding max width, rhs expresion being moved to the next line, impact of comments, etc.).

I haven't really thought through what it would take to implement such a style, but I suspect it may require an intrusive code change. Seems like it'd probably require inspecting the in-scope statements to determine the longest pattern for determining the infix spacing, and then using that spacing for the infix instead of the current/default of one space.

Some places in the codebase that may be of interest for this:

rustfmt/src/formatting/items.rs

Line 49 in 4e72871

impl Rewrite for ast::Local {

rustfmt/src/formatting/stmt.rs

Line 77 in 4e72871

impl<'a> Rewrite for Stmt<'a> {

https://github.com/rust-lang/rustfmt/blob/master/src/formatting/visitor.rs#L118

[johnnyutahh]

Your thorough writeup is super-duper helpful @calebcartwright. If we can contribute anything we will message back here.

Big thanks again.