[unstable option] control_brace_style

[scampi]

Tracking issue for unstable option: control_brace_style

[JosephTLyons]

Would love to have this feature stabilized. Having else statements on the same line as the closing brace of an if block is the only thing about rustfmt that bothers me, so this is the only setting I have in my rustfmt.toml file.

[jtk18]

Does anyone know what's holding this up from being stabilized? Any information would be appreciated. Thank you!

[Learath2]

Is there a reason this still isn't stabilized?

[nekodjin]

Why hasn't this been stabilized yet?

[calebcartwright]

We have a well documented process for stabilizing options and all options are presumed to need to remain unstable unless and until they can easily clear those thresholds, regardless of whether an option is 5 days old or 5 years old.

This option isn't stable because that hasn't happened yet, not to mention a bug reported with the still unstable option within the last 24 hours

[nekodjin]

Thank you.

[VPaulV]

Hi Guys! Is it possible to add an option that AlwaysNextLine would not force the empty _ => {} on the next line?:

fn print_some_more(x: i32) {
    match x
    {
        0 | 1 | 10 => println!("x is one of zero, one, or ten"),
        y if y < 20 => println!("x is less than 20, but not zero, one, or ten"),
        y if y == 200 => println!("x is 200 (but this is not very stylish)"),
        _ =>
        {}
    }
}

Probably we could have an additional flag like for fn_single_line = true?

[lukesneeringer]

Setting either non-default value to control_brace_style also (unexpectedly, in my view) prohibits any if-else or let-else from being on a single line.

So, for instance, using ClosingNextLine:

// Expected
let foo = if bar { 0 } else { 1 };

// Actual
let foo = if bar {
    0
}
else {
    1
}

This overrides single_line_if_else_max_width and single_line_let_else_max_width, and I assert it should not.

[aspizu]

this option still breaks for match arms.

[Houtamelo]

Edit: added 2nd design idea.

I would like to suggest a 4th option: "MultiNextLine". The idea is, it acts like either "AlwaysSameLine" or "AlwaysNextLine", depending on how many lines the condition expression has:

Single line condition:

if x < 5 {
    println!("Less than 5");
} else {
    println("Greater or equal to 5");
}

Multi line condition:

if vec.iter().find_map(|x| x < 5)
&& let Some(s) = option
{
    println!("multiline expr true");
} else {
    println("multiline expr false");
}

Alternatively, this could be a separate setting altogether: delay_braces_after_multiline_statements: true | false It acts differently depending on control_braces:

When delay_braces_after_multiline_statements == true:

match control_braces {
    AlwaysSameLine => {
        // Overrides
        if vec.iter().find_map(|x| x < 5)
        && let Some(s) = option
        {
            println!("multiline expr true");
        } else {
            println("multiline expr false");
        }
    }
    AlwaysNextLine => {
         // Does Nothing
        if vec.iter().find_map(|x| x < 5)
        && let Some(s) = option
        {
            println!("multiline expr true");
        } 
        else 
        {
            println("multiline expr false");
        }
    }
    ClosingNextLine => {
        // Overrides top brace only
         if vec.iter().find_map(|x| x < 5)
        && let Some(s) = option
        {
            println!("multiline expr true");
        }
        else {
            println("multiline expr false");
        }
    }
}

If any of these designs are accepted (for experimentation of course), I am willing to contribute a PR implementing it.