Combining openings and closings

[joshtriplett]

(Suggestions welcome for a better title.)

This arose from a discussion in a style-team meeting, as well as discussions in #35.

A generalized rule that may apply to structs, function calls, closures, match arms, and similar: If you have an outer construct that takes a single expression parameter (a struct with a single field, a function with a single parameter...), and that single expression in turn consists of a construct containing a list that needs breaking across multiple lines, you can break the inner list across multiple lines without first breaking the outer thing across multiple lines.

Concretely:

foo(bar(
    param1,
    param2,
    param3,
));

foo(Bar {
    x: value,
    y: value2,
});

let opt = Some(Struct(
    long_argument_one,
    long_argument_two,
    long_argument_three,
));

do_thing(|param| {
    action();
    foo(param)
});

// at the end of some block
Ok(some_function(
    long_argument_one,
    long_argument_two,
    long_argument_three,
))

I've seen this pattern extensively in Rust code.

This may nest further, as long as all but the innermost construct have only a single argument:

Ok(bar(baz(
    param,
    param2,
)));

This should never apply if the outer construct contains more than just the single expression; for instance:

// don't do this
let thing = Struct(first, OtherStruct(
    second,
    third,
));

// don't do this either
foo(thing, bar(
    param1,
    param2,
    param3,
));

[joshtriplett]

(Posting this as a separate comment so people can evaluate it and react to it independently.)

As a possible exception to the requirement that the outer construct must have only one argument, you can also apply this to an invocation of print!, println!, or format!, where the first argument consists of a format string and the second argument consists of a single expression:

println!("Thing: {}", generate_thing(
    long_argument_one,
    long_argument_two,
    long_argument_three,
));

This form similarly nests:

println!("Thing: {}", transform_into_thing(SomeStruct {
    f1: long_argument_one,
    f2: long_argument_two,
    f3: long_argument_three,
}));

process_string(format!("some prefix: {}", func(
    long_argument_one,
    long_argument_two,
    long_argument_three,
)));

[joshtriplett]

(Posting this as a separate comment so people can evaluate it and react to it independently.)

This can also apply to match arms:

match opt {
    Some(x) => somefunc(anotherfunc(
        long_argument_one,
        long_argument_two,
        long_argument_three,
    )),
    None => Ok(SomeStruct {
        f1: long_argument_one,
        f2: long_argument_two,
        f3: long_argument_three,
    }),
}

[gsingh93]

It seems like this goes against some principles that were involved with other style decisions, such as preserving blame. If any one or a combination of the opening identifiers is renamed such that the line grows too long, the block will be moved to the next line and all the block contents will be indented, breaking blame.

I'm not strongly against this, but I wanted to bring that up.

[est31]

I'm strongly in favour, but I'm running a highly customized config file already, so would be happy too if it weren't the default but there was a setting. Also, would like a setting where you could optimize the second/third/etc. argument in a similar fashion as well, not just the first (contrary to this proposal).

[nrc]

Related, rust-lang/rustfmt#1494, is about combining closures and function calls (specifically where the function just has a single arg).

[nikomatsakis]

This should never apply if the outer construct contains more than just the single expression; for instance:

I'm curious what you think about closures as the last argument. For example:

foo.map_or(x, || {
    foo;
    bar;
    baz;
});

It seems like this would be formatted as:

foo.map_or(
    x,
    || {
        foo;
        bar;
        baz;
    });

[nrc]

Moving to FCP, I would like to propose we accept the original proposal plus the extension to match arms, and closures, but not format strings. I think we may consider format strings later, but there are some other special cases there that I'd like to consider at the same time, so I'd rather punt for now. E.g.,

println!(
    "a {} format {} string {:?}",
    var1, var2, var3,
);

Re closures, I would like to restrict this to block closures, and in this case we allow any number of parameters as long as everything up to the { of the closure fits on one line (including inside the 'short' heuristic for function args), e.g.,:

foo(1 + 2, x, some_variable.bar(), |x| {
    closure_body();
    ret_value
})

[joshtriplett]

On May 8, 2017 9:04:33 PM PDT, Nick Cameron ***@***.***> wrote: Moving to FCP, I would like to propose we accept the original proposal plus the extension to match arms, and closures, but not format strings. I think we may consider format strings later, but there are some other special cases there that I'd like to consider at the same time, so I'd rather punt for now. E.g., ``` println!( "a {} format {} string {:?}", var1, var2, var3, ); ``` Re closures, I would like to restrict this to block closures, and in this case we allow any number of parameters as long as everything up to the `{` of the closure fits on one line (including inside the 'short' heuristic for function args), e.g.,: ``` foo(1 + 2, x, some_variable.bar(), |x| { closure_body(); ret_value }) ```

Sounds good to me. +1