The period is necessary in human languages because we write sentences next to each other and we need some way to separate them. Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course.
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.
Being able to write if and while loops with am empty body is due to braces being optional if you only have one statement and due to the empty statement being a legal statement (doing so keepsthings simpler).
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
The semicolon following the conditional is an empty statement; it ends the if statement equivalently to "if (something()) { }". It's not often seen, but sometimes can be found in:
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.
> 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.)
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:
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.