Make (Some) Separators Optional

[ExpHP]

@josh

Right now, we have a very consistent rule: you need semicolons after any construct that doesn’t take braces, and you need to omit the semicolon after any construct that takes braces.

This is patently false. Rust accepts semicolons after many of the constructs that you list, and sometimes it requires them! (not at the parsing stage, but rather; the lack of a semicolon causes it to be type-checked against ())

fn main() {
    if true { 3 } else { 4 }; // <-- this semicolon is REQUIRED, else type error!
    let _ = 2;

    loop {
        break 2;
    }; // <-- this semicolon is REQUIRED, else type error!
    let _ = 2;
}

I'm not saying that the above is useful; but I dare not call rust's rules for semicolons intuitive or consistent!

---

Edit: Or then again, I did say it myself that ; is a statement. Maybe these are parsed as loop {...} (some sort of "expression statement"), ; (a statement), and let _ = 2; (a statement)?

[leonardo]

-1 from me for allowing code like:

struct Zerg { ... }; 

In D language we have had to work a lot to disallow things like that.

Instead of messing with the language, it’s better to introduce auto-fixes in the editors/IDEs, in the rustfmt, etc.

[josh]

Agreed completely. Let’s have one canonical syntax, please, rather than trying to hide errors.

[Soni]

I’m not sure if it has been mentioned but Lua had newlines as a token until recently. now it’s just whitespace and the devs like it better that way.

Ambiguous cases by removing semicolons:

a.b()
(c.d)(e)

This will likely just error. In Lua it errors at runtime (usually). Then you can just insert a semicolon where needed.

Just because it messes with your brain doesn’t mean it’s bad. Coffee also messes with your brain.

[gbutler]

@Soni

This will likely just error. In Lua it errors at runtime (usually). Then you can just insert a semicolon where needed.

Just because it messes with your brain doesn’t mean it’s bad. Coffee also messes with your brain.

I truly hope this sentiment doesn't take hold in Rust. This kind of ambiguous nonsense should be avoided at all cost.

[Soni]

at least it’s not context-sensitive.

[H2CO3]

@Soni

Just because it messes with your brain doesn’t mean it’s bad

Ouch. It's exactly because it's easy to use incorrectly that it is bad. Rust is not the average fast-and-loose scripting language. Rather, it is meant to emphasize safety and correctness as its number one goal. "It might break silently or at runtime because whitespace" doesn't match with that goal by any standard.

[gbutler]

@H2CO3

“It might break silently or at runtime because whitespace” doesn’t match with that goal by any standard.

Unfortunately, the forum only allows but one heart to give!

[H2CO3]

@anon2808951

As is, Rust’s mandatory semicola are inconsistent, irritating and unnecessary.

They might be subjectively irritating for some people; however, they are neither inconsistent nor unnecessary. As several other people and I have explained above, they are necessary for unambiguous parsing. No question about that.

[Centril]

@H2CO3

Rust is intentionally not the “”“convenient”"" whitespace language

This is not true. The reason why Rust doesn't use layout syntax is simple: there's only so much in the complexity budget, and {, } and ; is used so that the language is more familiar to those who know a C-family language (C, C++, Java, and many more...).

It has nothing to do with some supposed objective drawback in readability of layout syntax. If you want to argue that and convince me, please provide some evidence.

That said; I don't think introducing layout syntax or omitting ; in Rust is a good idea; the language is just not designed to be like Haskell, and so adding it after the fact won't lead anywhere good.

[Ixrec]

@anon2808951

impl Foo1;

is not valid syntax with or without a semicolon.

When we stick to things that are valid syntax in the first place, we get the aforementioned arguably consistent rule that an item ends in either a semicolon or a closing curly brace, but not both:

struct Foo1;    // allowed
struct Foo1     // not allowed
struct Foo2 {}  // alowed
struct Foo2 {}; // not allowed
struct Foo3();  // allowed
struct Foo3()   // not allowed

impl Foo1 {}    // alowed
impl Foo1 {};   // not allowed

(I have no particular opinion on whether this is the ideal rule for semicolon placement, but it does appear to be a consistent rule; I just want a lint against unnecessary semicolons)

[Centril]

@Ixrec

When we stick to things that are valid syntax in the first place, we get the aforementioned arguably consistent rule that an item ends in either a semicolon or a closing curly brace, but not both:

(Unless you are inside an fn body where ; is allowed and sometimes required after }, which imo makes the rule too complicated to be consistent)

[CAD97]

I don’t disagree, but I’d like to say that in statement context the punctuation is not required, but it is in expression context[^1].

The reason for the grammar allowing “optional” semicolons in statement position is that a bare semicolon in statement position is allowed as an empty statement.

[^1]: except I need to qualify that for match where the => { ... } brackets are an expression but don’t need a ,.