Add support for leading comma

[tulis]

Not everyone likes to use trailing comma. Most of the time users' eyes behavior would focus more on the left-hand side of the monitorsand therefore it is very easy to spot on whether it is leading comma or other rust operators, such as =>, +, ., etc.

    match io::stdin().read_line(&mut buffer_input) {
        Ok(buffer_input_size) 
            => println!(
                "Hello, {}! Your name size is {}."
                // call .trim() because .read_line also read `\n` character at the end of input
                , buffer_input.trim()
                , buffer_input_size
            )
        , Err(error) => println!("[Error] Cannot read input. Reason: {}.", error)
    };

[calebcartwright]

Thanks for reaching out with your request!

As you may already be aware, rustfmt's main job is to reformat input code according to the style codified in the Style Guide, and that's why the closing braces are formatted they way they are.

rustfmt is still configurable nevertheless, largely to support some of the formatting decisions that cover the style topics large portions of the developer community find contentious (spaces vs. tabs, etc.). Generally speaking we're open to the inclusion of new configuration options, provided the default value still aligns with the Style Guide, but we do also have to consider whether the impact on the codebase and associated maintenance, bug surface, etc. is tolerable in the context of option and style it produces. For a wildly hyperbolic example, we wouldn't accept a new option that doubled the size and complexity of the codebase for a bespoke style that'd only be used by one or two developers because such a change would be far too much of a burden on rustfmt's main job.

I'm not adamantly opposed to supporting this, but it's also not something that the rustfmt team is ever likely to work on due to the sharp divergence from our core style goal and comparatively minimal appetite for this custom styling option. However, if you or anyone else feels strongly enough about wanting to have this and are willing to submit a PR with an implementation then we'll certainly review and take into consideration!