Feature Request: Avoid brackets on if (And similar) statements

[AndroGR]

I believe it would come in handy if we could do something like this:

fn main() -> Result<(), String>
{
    if 1 == 3
        println!("1 is equal to 3!");
    else {
        println!("1 isn't equal to 3... (Well what do you expect?)");
        Err(String::from("1 wasn't equal to three and you get punished."))
    }
}

Clearly, there isn't any reason to waste space and typing on brackets on the first statement. It is already pretty straightforward.

Another advantage would be that this basically breaks no code. At the worst case, the compiler will implicitly insert brackets at compile time. Also I think it's known to everyone many C and C++ compilers support this.

Last, we could extend this to simply being indentation based (Like Python) and make brackets completely optional, but that's too crazy of a change for me so I won't elaborate further.

[bjorn3]

@AndroGR

Also I think it's known to everyone many C and C++ compilers support this.

And there it has caused more than one security issue due to confusion about what is inside and outside of the if.

[jkugelman]

This has come up before:

Optional curly brackets

Note that Java has required parens, as you just used there, because it has optional braces. Rust makes the opposite choice, and has optional (even discouraged) parens around the condition, but required braces around the block: if doHelloWord { println!("Hello world!"); } Given that everywhere I've worked in C-like languages has ended up having a coding standard requiring braces even through they're optional in the language, I think Rust makes the better trade-off here.

Optional curly brackets

Even if it was possible (and it is not, as others said here), it would open the door to bugs like Apple's goto fail;. I don't want Rust to do the same mistake.

Optional curly brackets

Mandatory curly braces are an intentional design choice. Optional braces don't provide the ability to write cleaner code, quite the opposite. They are a common source of mistakes, like dangling else or bad block nesting. It's part of the features that Graydon Hoare (the original creator of Rust) is very proud that Rust shipped without: https://graydon2.dreamwidth.org/218040.html

Optional curly brackets

As one of the maintainers of the parser and resident invalid code recovery experts, my face contorted while reading this proposal and thinking about the fallout from it. There's nothing stopping us from making the parser recover and provide structured suggestions when code like this is written. There's nothing stopping rust-analyzer from auto-applying the surrounding braces around the code when the confidence is high. But I would put my foot down (not that it could realistically stop any popula…

[scottmcm]

@AndroGR

Also I think it's known to everyone many C and C++ compilers support this.

To re-use my most-liked post on this forum:

Optional curly brackets

Note that Java has required parens, as you just used there, because it has optional braces. Rust makes the opposite choice, and has optional (even discouraged) parens around the condition, but required braces around the block: if doHelloWord { println!("Hello world!"); } Given that everywhere I've worked in C-like languages has ended up having a coding standard requiring braces even through they're optional in the language, I think Rust makes the better trade-off here.

[josh]

I think we need a "frequently asked questions" or "frequently proposed ideas" or similar, and this should probably be near the top of the list.

[mathstuf]

Is there a Discourse plugin that could detect "feature request" from brand-new accounts and perhaps interject "have you looked at the FPI list first?" kind of assistance?

[scottmcm]

@AndroGR

Last, we could extend this to simply being indentation based (Like Python) and make brackets completely optional

Note that even Python doesn't support

@AndroGR

    if 1 == 3
        println!("1 is equal to 3!");

Instead, it requires

if 1 == 3:
    print('1 is equal to 3!')

with a colon that is technically completely unnecessary.

Total minimalism of syntax isn't good for humans.

[tczajka]

This would also create ambiguities in the syntax, for instance:

if 10 > 3 - 2 - 1 else -4

if foo[1][0] else return

[ekuber]

We need the anti-RFCS repo: design proposals that will not happen.

[quinedot]

Frequently Requested Changes?