As a sometime C++ dev, I fully recognize the utter inanity and burden of typing semicolons where the compiler should know perfectly my intent, and would rejoice in a language that did away with them. In fact, it's one of the features of Go that I really like. Rust's syntax, on the other hand, feels like a step backwards in some ways.
I wrote a bit more here: https://news.ycombinator.com/item?id=5608157.
More practically, it seems to remove a class of errors. Semicolons are optional in Javascript and I've seen posts here about subtle errors that can creep in when you change code a little carelessly.
And even more practically, it allows you to type "one liners" into things like REPLs even if they aren't one liners.
Just my two cents.
Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an optional measure if you do want to cram several statements together on the same line. You mention one-liners; a semicolon-free language can support semicolons. Here's a Ruby one-liner:
>> b = Box.find(3); t = Thing.new; b.add_thing(t)
A class of errors: Well, anecdotally, I have personally never had a single issue with semicolons in JavaScript in all my years developing with it, simply because I always use semicolons. The reason is that JavaScript has a bunch of "semicolon insertion" rules that are not well understood, so dropping the semicolons is a bad idea, as the recent "fiasco" showed, and I just decided very early on not to go that route.As I understand it, JS is a semicolon-enforced language that allows you to drop them at your convenience, whereas Ruby, for example, is a semicolon-free language that allows you to include them at your convenience. I'm not a parser expert, and I won't swear there is a significant difference except in which rules are defined. But I do know that semicolons are categorically not an issue in Ruby. So I would say that this argument is invalid, too, because it presents a flawed language as the ideal. The Rust guys should not need to base their design on JavaScript.
if (something()); { somethingOther(); }
The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.
As for the second {}, its to allow you to create inner scopes where you can declare variables with a more restricted scope without needing to do something silly like "if(true)".
Empty block statements are OK sometimes with while and for loops when the real action that matters is in the condition:
while(!trySomething()){} //empty body for the loop
And since these language for (i = 0; a[i] != x; i++) ;
to find the first index equaling x.Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.
But if you have
if (something()); { somethingOther(); }
Then you have a new problem: you intended the braced statement to execute iff the if-statement evaluated to true. But since you put the semicolon after if by accident, now the braced part will execute no matter what the if-condition evaluates to.
(my point was about unintentional use of semicolon after if-statement - in which case always using braces doesn't seem to help.)
> Basically, ending an expression in Rust with a semicolon ignores the value of that expression. This is kinda weird. I don't know how I feel about it. But it is something you should know about.