Add options to not wrap long collections

[andradei]

An options, perhaps ignore_arrays, that would keep the following format:

let mut board: [[char; 3]; 3] = [
    ['O', 'O', 'O'],
    ['O', 'O', 'O'],
    ['O', 'O', 'O']
];

Instead of inlining everything like it does now:

let mut board: [[char; 3]; 3] = [['O', 'O', 'O'], ['O', 'O', 'O'], ['O', 'O', 'O']];

[nrc]

Are you after something specifically for arrays of arrays or for array literals in general?

[andradei]

Arrays of arrays (or of vectors, or other collection type that can be represented that way).
Perhaps something that mimics the formatting of structs:

struct Point {
    x: i32,
    y: i32,
}

[Ryman]

Similar cases from exercism/rust#143.

-    run_test(&[
-        "   ",
-        "   ",
-        "   "
-    ]);
+    run_test(&["   ", "   ", "   "]);

-    let lines = vec![
-        "  +-+",
-        "  | |",
-        "+-+-+",
-        "| |  ",
-        "+-+  "
-        ];
+    let lines = vec!["  +-+", "  | |", "+-+-+", "| |  ", "+-+  "];

The reformatting really hurts readability for seeing the structure in the strings.

[ytmimi]

It's been a long time since this issue was opened . Confirming this is still reproducible with rustfmt 1.5.1- (f2c31ba0 2022-07-19) using the default configs. These days rustfmt has the array_width option which can be used to configure the max width of an array before it needs to wrap. Although it's not a perfect solution we can use array_width to get the desired formatting.

Input

fn main() {
    let mut board: [[char; 3]; 3] = [
        ['O', 'O', 'O'],
        ['O', 'O', 'O'],
        ['O', 'O', 'O'],
    ];
}

output array_width=60 (Default)

fn main() {
    let mut board: [[char; 3]; 3] = [['O', 'O', 'O'], ['O', 'O', 'O'], ['O', 'O', 'O']];
}

Output array_width=48 (highest value I could find that forces a wrap)

fn main() {
    let mut board: [[char; 3]; 3] = [
        ['O', 'O', 'O'],
        ['O', 'O', 'O'],
        ['O', 'O', 'O'],
    ];
}

[sourcefrog]

Although you can approximate it by specifying the width, it would be nice to express the intent more directly by saying that arrays containing compound members should have one member per line. (Though, I suppose this does not help the case with strings...)

[ytmimi]

Agreed that this isn't a direct solution, but just wanted to mention it. @sourcefrog would you mind providing a code snippet for the case you're envisioning.

[sourcefrog]

The first comment on this bug is an example of it. If it's an array (of length>1) of arrays, structs, or tuples (also non trivial) maybe there should be an entry per line.

[ytmimi]

Sorry, but I'm having trouble following. Could you please post the snippet that you had in mind. I think If I see it I might be able to understand it a little easier.

[sourcefrog]

instead of this

let mut board: [[char; 3]; 3] = [['O', 'O', 'O'], ['O', 'O', 'O'], ['O', 'O', 'O']];

it should produce this:

let mut board: [[char; 3]; 3] = [
    ['O', 'O', 'O'],
    ['O', 'O', 'O'],
    ['O', 'O', 'O']
];

However, if the elements of the array are scalars it should keep the current behavior of folding onto a single line, if it fits:

let mut board: [char; 9] = ['O', 'O', 'O', 'O', 'O', 'O', 'O', 'O', 'O'];

[calebcartwright]

@ytmimi - AIUI it's just reiterating the original ask from ~6.5 years ago even though there are existing width-based options that can approximate the end result.

To be honest, my inclination from a purely-trying-to-cleanup-the-backlog perspective is to close this given the age. I understand the ask and desire expressed by a couple folks, but this isn't something that we the rustfmt are ever going to work on, and no one else has taken a pass at in ~6.5 years either.

However, it probably wouldn't be too difficult to implement, nor for us to try to maintain, if someone else wanted to attempt to implement it.

I suspect you'd just need to incorporate logic to determine a separator tactic based on the contents at the following sites (assuming this is desired for slices too):

rustfmt/src/patterns.rs

Lines 249 to 257 in f2c31ba

	PatKind::Slice(ref slice_pat) => overflow::rewrite_with_square_brackets(
	context,
	"",
	slice_pat.iter(),
	shape,
	self.span,
	None,
	None,
	),

rustfmt/src/expr.rs

Lines 69 to 77 in f2c31ba

	ast::ExprKind::Array(ref expr_vec) => rewrite_array(
	"",
	expr_vec.iter(),
	expr.span,
	context,
	shape,
	choose_separator_tactic(context, expr.span),
	None,
	),

Where I worry the complexity would come in would really be around trying to determine which types of contents warrant that classification, and of course thinking about it from a rustfmt perspective vs. a personal preference (i.e. how could rustfmt support different user preferences for what qualifies)