Feature Request: Add spaces_within_parenthesized_items Option

[henriquemelicias]

Discussion for spaces_within_parenthesized_items configuration option. Implemented by #5434.

This option enforces consistent spacing directly inside of parentheses, by putting one space to the right of '(' and to the left of ')' in parenthesized items, such as function calls:

fn ipsum_lorem(arg1: usize, arg2: usize, arg3: usize) to fn ipsum_lorem( arg1: usize, arg2: usize, arg3: usize )

I do believe there are cases where having these spaces do improve readability, for example on calls:

ipsum_lorem<T>(dolor_amet<T>(string)); to ipsum_lorem<T>( dolor_amet<T>( string ) );

Although I do understand that at the end of the day it is very subjective.

This option goes against some behaviours of the Rust Style Guide: Single line calls and tuple literals.

Discussion topics:

• Should tuple literals and struct tuple literals follow this rule as well?

  (a, b, c)
  Foo(a, b)

to

( a, b, c )
Foo( a, b )

• What if there's comments and there's no parenthesized item, should spaces be added?

  foo(/* comment */);

  to

  foo( /* comment */ );

• What about attributes?

  #[cfg(test)]

  to

  #[cfg( test )]

• Patterns and grouping parentheses ?

  (1 * ((2 + 3) * 4)

  to

  ( 1 * ( ( 2 + 3 ) * 4 ) ) // I think grouping parentheses should not be included.

• Is there a possibility of having the same rule for other symbols such as <> and []? You could write an array like this [ 1, 2, 3, 4, 5 ] and vec![ 1, 2, 3, 4 ].

Cheers!

[ytmimi]

@henriquemelicias I appreciate you opening this issue. I made a few tweaks to the title and description to better reflect that this is feature request. I think if we decide to move forward with the option we can add a separate issue to track stabilization.

[calebcartwright]

I think this falls in a similar theme as requests like #3564.

Though not an entirely uncommon style in certain other programming languages, it's not common at all for Rust code in my experience. I could see this being something folks coming from other languages may want to reach for at first due to subjective preference and/or familiarity as compared to non-Rust languages. However, like the author of #3564, I would also envision many of those same folks abandoning this style after becoming more used to Rust and not wanting to go against the grain.

As such I have some reservations, however, and again similar to #3564, it is a small and non-intrusive code change so I think we can certainly consider supporting it.

[wcravens]

In my team, this isn't a style issue, it's an accessibility issue. Space immediately inside opening and closing parens is easier to read for some of our older team members. This currently stops us from integrating rustfmt into our project.