More brace locations

More control over braces' style

It would be nice to further separate different "kinds" of braces currently englobed by the brace_style and control_brace_style settings.

For example, I usually prefer the "AllMan" (AlwaysNextLine) style for its clear readability, but there are some places where it feels really clunky.

Examples

Here are some examples that I feel are « meh »:

Note : « bad » and « good » in the following examples are of course only expressing my personal likings and I understand these are in fact the heart of the debate, so please do not take it to heart.

Conditional expression as assignment's rhs

This one is probably the worst for me, because I otherwise really like the allman style, even for control expressions, as long as they are not in the right side of an assignment.

Also note that it's also the case for the block after a match matched_expression.

// although I like the allman style, I hate this...
let variable = if condition
{
    if_true_val
}
else
{
    if_false_val
};
// ... and would love to have this...
let variable = if condition {
    if_true_val
} else {
    if_false_val
};
// ... instead

match arm's blocks

// bad :
match option
{
    Some(expr) =>
    {
        // do some stuff
        "blah"
    },
    None => "this is fine without a block expression",
}
// good :
match option
{
    Some(expr) => {
        // do some stuff
        "yes please"
    },
    None => "this is (still) fine without a block expression",
}

enum variants with named fields

// bad :
enum Enumeration
{
    SimpleVariant,
    TupleVariant(String),
    StructVariant
    {
        this: &'static str,
        is: String,
        annoying: !,
        // (especially when you only have structured variants)
    },
}
// good :
enum Enumeration
{
    SimpleVariant,
    TupleVariant(String),
    StructVariant {
        this: &'static str,
        is: String,
        better: !,
    },
}

PS : that being said, how are new rustfmt features decided ? Is it subject to the RFC process ?

EDIT : I think those three cases are the main reasons I would like to see more flexibility in the configuration of braces' style, but I'll give you some more if I can think about other situations (unrelated to those previous ones, naturally)

EDIT : although it's only three different cases for my personal use case, some other people with different preferences might also want more flexibility for braces' style in other situations.

Start by reviewing the existing brace_style and control_brace_style settings against the conditional-assignment, match-arm, and enum-variant examples in the issue. Determine a maintainable configuration design and how the new cases should be specified; done means the requested brace categories have agreed behavior and coverage.