[luser001]

I personally like semicolons. It's similar in spirit to the period of English. Even languages which didn't traditionally have the period have adopted it in the last couple of centuries.

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.

[lobster_johnson]

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.

[Dewie]

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this:

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.

[ufo]

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

And since these language

[pcwalton]

This error can't happen in Rust. If blocks must be braced.

[mcguire]

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.

[Dewie]

> 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.)