Why do some programming languages allow semicolons to be automatically included?

325 Views Asked by At

Languages such as C++ will not work if semicolons are forgotten but other languages such as JavaScript will automatically include them for you.

I know from this article Do you recommend using semicolons after every statement in JavaScript?, that it is recommended to use semicolons and there are scenarios that can create unwanted ambiguities (such as dangling else in C++ when braces aren't used).

At some point in time there must have been a decision to make them optional (e.g. when the creators of JavaScript made the conscious choice to make it optional).

I would like to know why this decision was made and how it is beneficial to users of these languages.

Background: I am a novice coder and have only recently began learning JavaScript.

EDIT: To the comments that are saying it is bad in JavaScript, I know. I'm asking why it is allowed to happen in the first place, if most people consider it bad practice.

4

There are 4 best solutions below

0
On BEST ANSWER

Regarding JavaScript, Douglas Crockford explains the origins of the idea in this video. (It's a great talk and it's really worth your time to watch it if you intend to continue pursuing JavaScript.)

This is a direct quote from the talk:

Semicolon insertion was something intended to make the C syntax easier for beginners.

As far as how it's beneficial to users of the language, Crockford explains in detail a few reasons why it's not beneficial, but rather how it introduces very serious ambiguities and gotchas into the syntax. One of the most notable cases is when attempting to return an object literal using a braces-on-the-left coding style (source from the video):

return
{
    ok: false
};

Which actually returns undefined, because semicolon insertion adds one after return, and the remaining intended object literal gets parsed as a code block, equivalent to this:

return;
{
    ok: false;
}

Trying to make a language easier for beginners can be a great source of well-intentioned blunders.

0
On

Long ago, in the distant, dusty past, things like this were done primarily to make up for the fact that compile/link/run cycles were measured in hours at a minimum, and often ran more than a day. It could be (okay: was) extremely frustrating to wait hours for a result, only to find that the compiler had stopped at line 3 (or whatever) because of some silly typo.

To try to combat that, some compilers of the time tried to second-guess your intended meaning, so if a typo was minor enough (for some definition of "minor enough") it would assume it knew what you really intended, and continue compiling (and potentially even executing) despite an error.

Those who fail to study history are doomed to repeat it. A few who are just too arrogant to learn from history repeat it as well. There's probably room for considerably debate about the exact sort of character defect that would lead a language designer to make this mistake at the present time. There is much less room (none at all, really) for argument about whether it is a mistake though--it clearly is, and an inexcusable one at that.

0
On

The author of the JavaScript language, Brendan Eich, has a blog post on this subject called The infernal semicolon on the topic of Automatic Semicolon Insertion (ASI).

Relevant quotes:

ASI is (formally speaking) a syntactic error correction procedure.


I wish I had made newlines more significant in JS back in those ten days in May, 1995. Then instead of ASI, we would be cursing the need to use infix operators at the ends of continued lines, or perhaps or brute-force parentheses, to force continuation onto a successive line. But that ship sailed almost 17 years ago.


My two cents: be careful not to use ASI as if it gave JS significant newlines.

0
On

in javascript, the semi colon is a statement seperator, but so is newlines, so you don't need them if you have a statement per line.

other languages, like C++, only have ; as a seperator, and whitespace like newlines, do nothing. There are pros and cons

in C++ it means the syntax is consistent

if you write

int x=0;
x++;

if you then compress to one line, its the same general syntax :-

int x = 0;  x++;

in javascript if you write

var x=0
x++

then if you compressed to one line

var x=0 x++

would be a problem

you'd need to do var x=0; x++

So, the big thing is whether whitespace is significant or not. Ideally a language would consistently use one mechanisim. But for javascript it is mixed so it leaves a bit of ambiguity when to use ;