Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unstable option] control_brace_style #3377

Open
scampi opened this issue Feb 13, 2019 · 13 comments
Open

[unstable option] control_brace_style #3377

scampi opened this issue Feb 13, 2019 · 13 comments
Labels
unstable option tracking issue of an unstable option

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable option: control_brace_style

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@scampi scampi changed the title [unstable option] unstable option: control_brace_style [unstable option] control_brace_style Feb 18, 2019
@JosephTLyons
Copy link

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
Copy link

jtk18 commented Apr 16, 2020

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

@Learath2
Copy link

Is there a reason this still isn't stabilized?

@nekodjin
Copy link

Why hasn't this been stabilized yet?

@calebcartwright
Copy link
Member

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
Copy link

Thank you.

@VPaulV
Copy link

VPaulV commented Apr 13, 2023

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
Copy link

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
Copy link

aspizu commented Feb 7, 2024

this option still breaks for match arms.

@Houtamelo
Copy link

Houtamelo commented Jun 29, 2024

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.

@lolbinarycat
Copy link

came to this repo to see if something like MultiNextLine existed, and to propose it if not...

looks like someone beat me to it! i would also be willing to create a PR for this, if desired.

this is honestly the biggest thing i want from rustfmt, and is the main reason i don't use it in personal projects.

@diocletiann
Copy link

diocletiann commented Dec 21, 2024

Looking forward to "ClosingNextLine", indented, non-spaced else if is hard to read. This my only real issue with rustfmt.

@lolbinarycat
Copy link

iirc, the current behavior of AlwaysSameLine is actually that of the proposed MultiNextLine?

idk if this was a recent change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unstable option tracking issue of an unstable option
Projects
None yet
Development

No branches or pull requests