Define 'short'

[nrc]

Currently Rustfmt treats certain items differently if they are 'short'. For example, it will but a short struct literal on one line:

// Short
let x = Foo { x: 42 };

// Not short
let opts = Options {
    flag_package: vec![],
    flag_jobs: None,
    flag_features: vec![],
    flag_all_features: false,
    flag_no_default_features: false,
};

As @joshtriplett points out in #31 (comment), we should have one global definition of 'short' rather than a different definition every time.

I see two ways to define 'short' - absolute characters (e.g., 25) or proportion of max line length (e.g., 1/4). One might argue that no matter how long the line length, what makes (e.g.) a struct literal readable on one line does not change. On the other hand, people who prefer longer lines might also prefer more on one line in these cases.

[nrc]

Places where I think this should kick in (off the top of my head) are struct variants (discussed in #31), struct literals, and function calls. There might be other places we should consider this but currently don't. Rustfmt currently uses different values for all of these:

fn_call_width: usize, 60,
struct_lit_width: usize, 16,
struct_variant_width: usize, 35,

(from https://github.com/rust-lang-nursery/rustfmt/blob/master/src/config.rs).

That actually suggests we shouldn't have a universal value. I'd be happy for both struct values to be 25-ish, but function calls should probably be longer (we might reconsider the value, or if we need one at all given that we will almost certainly change how function calls are otherwise formatted).

[petrochenkov]

When formatting manually I use "short" limit == ideal_width == max_width.
I remember I was surprised when I saw rustfmt splitting lines that obviously fitted into 100 characters.

Where is "short" usually used? EDIT: Now I see the previous message which was written simultaneously with this one.
I'd understand if it were used in, e.g. enum definitions to split long variants, but not in function bodies.

[joshtriplett]

@nrc I honestly find it surprising that rustfmt has a different length for wrapping function calls, rather than using the normal line length. Its long length compared to the other two seems like an artifact of that; I'd advocate for using the line length for function calls.

For the other two, making them both the same length seems fine, if we decide to define "short"; literals don't seem different than struct variants in that regard.

That said, I think I'd still prefer to just use the normal line length here, and only limit struct literals and struct variants by the number of fields. I'd be fine with "at most three fields before splitting onto multiple lines, even if shorter than the line length", for instance. And that rule seems much easier to manually apply than counting characters.

I'd really like to avoid the scenario where I can't trivially recreate rustfmt's style by following easy-to-manually-apply rules with a bit of editor assistance. That's one of the biggest things that bothers me about a character-count-based definition of "short".

[nrc]

The use case for the function args is something like this:

    foo(an_object.call1().call2().field, something.foo + 42, top_fn(nested_fn(deep), bar(), baz()));

    // vs.

    foo(an_object.call1().call2().field,
        something.foo + 42,
        top_fn(nested_fn(deep), bar(), baz()));

That line (with a single 4 space indent) fits in 100 chars, but is pretty horrible to read, I much prefer to split the args to multiple lines and would do so myself if formatting manually.

[nrc]

With these heuristics we get in to formatting mostly for aesthetics/subjective readability. I realise that we lose some of the appeal of a very tight spec here, but I believe there is scope for making Rustfmt a better tool by using these somewhat arbitrary heuristics. My experience has been that we closely match what people do manually by doing this.

That said, I think I'd still prefer to just use the normal line length here, and only limit struct literals and struct variants by the number of fields.

This was not enough in the past - the size of fields (and types/arguments) varies widely and people when manually formatting tend to take into account actual size as well as number of fields.

I'd really like to avoid the scenario where I can't trivially recreate rustfmt's style by following easy-to-manually-apply rules with a bit of editor assistance.

I think this is subtly but importantly wrong. I think that it is important that we have a spec that can be easily applied by both tools and real people. I think that is should be an explicit non-goal that tools and people would apply exactly the same formatting. Basically, people and machines work too differently for this to end well. Furthermore, I don't see any advantage in people and tools coming up with exactly the same formatting (obvs there are advantages to the spec being manually implementable and for a tools' formatting to be predictable/unsurprising, but I don't think that applies to character-precision). By analogy, if we were specifying a drawing tool, we would want the output of the tool to be roughly recreatable by an artist, but we would not expect the output to be a pixel-precise match to the artist's output.

In practical terms, I think it is fine for the spec to be written in terms of both hard limits and recommendations - for example, for function calls the hard limit would be 'fits in the max line length' and the recommendation is something like 'functions may be spread over multiple lines if that makes reading easier' where a person interprets that how they like, and Rustfmt interprets that as > 60 chars.

[joshtriplett]

@nrc I would probably split that function call as well, but not because of length. If the last argument didn't consist of a multi-argument function call itself, I'd write that on one line. As written, I'd wrap it to avoid making people skimming the line have to deal with two levels of comma-separated arguments on the same line.

Regarding arbitrary numbers: I'd like all the formatting rules to remain simple enough that people can remember and apply them. Personally, I wish it could follow the 0-1-infinity rule, and "no more than one field on a line" would produce fairly reasonable results. But even something like "no more than three fields" seems much easier to manually apply than "no more than 60 characters".

[joshtriplett]

On a different note, I'd prefer to define "short" as an inclusive length (for instance, a struct literal including the structure name and braces) rather than exclusive (excluding the structure name as braces):

enum E {
//  v- this length ------------------------------v
    StructVariant { field1: Type1, field2: Type2 }
//                  ^- not just this length ---^
}

[nrc]

I would probably split that function call as well, but not because of length

I probably would split too, however, Rustfmt can't really do that so we have to make the most of what we have.

On a different note, I'd prefer to define "short" as an inclusive length (for instance, a struct literal including the structure name and braces) rather than exclusive (excluding the structure name as braces).

Can you explain why please?

For me, the motivation here is purely to make the arguments more readable, so I wouldn't want to split a_long_object.a_very_long_method_name(x, y, z) but I would want to split x.m(a_long_argument, another_long_argument) (waving hands about the actual lengths, and actually, manually, I would not actually split the second example because the arguments are not complex).

[joshtriplett]

I probably would split too, however, Rustfmt can't really do that so we have to make the most of what we have.

Rustfmt could apply the heuristic I described: "split an outer function call's arguments onto one line each if one of them contains an inner function call with multiple arguments". Not perfect (println!("{}", foo(a, b)); doesn't really need wrapping), but a decent approximation of the actual human heuristic. Split lines based on complexity and ease/speed of mental parsing, not length.

Can you explain why please?

For me, the motivation here is purely to make the arguments more readable, so I wouldn't want to split a_long_object.a_very_long_method_name(x, y, z) but I would want to split x.m(a_long_argument, another_long_argument) (waving hands about the actual lengths, and actually, manually, I would not actually split the second example because the arguments are not complex).

I wouldn't split either of those, based on the heuristic I just described; when I mentioned "inclusive" for lengths, I had structs and literals in mind, not function calls. But primarily, if you have to have a magic number, it seems easier to apply "inclusive" without manual counting; for instance, if you have a struct variant in an enum, you can easily check for an N-character inclusive limit by looking at editor columns and seeing if you passed N+4. To check against an N-character exclusive limit, you'd have to have an editor that shows the length of a selection, and select the relevant length.

[joshtriplett]

Copying some discussion here from other issues: I think I'd really prefer to define "simple" rather than "short". For instance, in the context of an enum struct variant, it doesn't matter to me how many fields the struct has or how many characters they take up (as long as they fit on one line), but as soon as a field has a non-trivial type, an attribute, or anything other than name: SingleTokenType, I'd want to break the fields onto separate lines, no matter how few characters they fit into.