That is one of the “features”, which is total misconceptions in language. I can’t see any reasons to skip semicolon. I always put explicitly semicolon. Semicolon insertion is job for developer, not for Tokenizator of the language. Automatic insertion is bad design.

Well, actually automatic semicolon insertion there’s in many languages (though, maybe it’s named differently), e.g. in Ruby, QML declarative, other. You can write (in Ruby):

def test
  10
end

or

def test; 10; end

the same result.

Yes, that’s true, that ECMAScript has some ambiguous (from the human logic viewpoint) features regarding to ASI (if not to know and not to understand how this mechanism works).

But in general, this idea can be not so bad. The question is in implementation and ES has some ambiguous cases in this place. That’s it.

What about me – I always put semicolon explicitly in ES. And about ES5 – yep, they could force put semicolon explicitly in “strict mode”, but as I already told in some forums – I believe “strict mode” feature itself as an error of language design. Be more exact – the error is not the “strict” technique as itself, but in distinguishing “strict” and “non-strict” modes, which will cause many useless holy wars and debates. Some will talk that’s professional code is only in strict – but that’s completely wrong.

By the truth, I think that ES has a bit overloaded syntax, I think it should omit some redundant C-style features, which is actually done in version 1.8 of SpiderMonkey – as you know there open curly brackets and return keyword in some cases are optional – the same can be with semicolon – maybe that’s why they do not force put it explicitly even in strict mode.

Dmitry.

I messed up #9, thinking that `x` in `x, y, this.x` has value of `20`, not `undefined`. Then realized where the mistake was (`bar`’s VO is followed by `foo`’s VO, not the object that `with` injected into the scope; lexical scoping keeps biting me from time to time ).

Yes, that’s it, [[Scope]] of `bar’ is already set; firstly this question appeared on es-discuss mailing list, there is also my explanation: https://mail.mozilla.org/pipermail/es-discuss/2010-February/010791.html

Minor nitpicks: question #2 is debatable. I kind of understand what you mean by “[...] algorithms of the following checks completely equivalent”, but if we were to be precise, ‘undefined’ == ‘undefined’ and ‘undefined’ === ‘undefined’ go through different algorithms. Former one goes through “The Abstract Equality Comparison Algorithm” (11.9.3), whereas latter one — through “The Strict Equality Comparison Algorithm” (11.9.6). Both go through steps 1,2,3,4 and 11, but step 1 in 11.9.3 is technically not the same as step 1 in 11.9.6. Therefore, I can say that algorithms are different.

Well, yeah, the main goal of this question is in the same types of operands and which imperative actions are taken applying algorithms. As types are the same, step 1, can be omitted to make this question more interesting than just “No, different algorithms (names) are used”.

The goal is to show that there’s no need to write (how we can see in many frameworks) strict equality with typeof operator and string operand.

About debatable – I think it will be better to form (more) correctly question title. Any suggestions?

it’s better to stay away from host objects (e.g. `alert`) as their unspecified nature makes questions ambiguous

Yep, true, I changed it to console.log, which is also, btw, host

Dmitry.

@joseanpg has provided a good explanation of the quiz (you can find it on his twitter page). Although, question #10 became debatable. In disclaimer there was said:

clear ECMAScript is used without non-standard features, augmentations of built-ins or any other extensions;

which if to be fair can make answer on question #10 wrong. So I’ve changed this point in disclaimer to:

clear ECMAScript is used without non-standard features, augmentations of built-ins or any other extensions, though can be the case of user-defined global objects;

although, simple global function – is an augmentation of the global object, and the global object – is a built-in object. And to keep this question more interesting (rather than just “Always ReferenceError”), I’ve clarified disclaimer point; but the answer of joseanpg fairly (if there’s no any user-defined functions) is correct too.

The main goal of this question is about automatic semicolon insertion (7.9, ECMA-262-3) and position of the open curly block’s bracket; “foreach” and “k” play minor role here. In contrast with:

// always SyntaxError
foreach (k in {a: 10, b: 20}) {
  // ...
}

which always will provide SyntaxError and thus will help to avoid error in logic of the program if user-defined function “foreach” exists and open curly block’s bracket is set on the new line:

// ReferenceError or possibly no error
// if "k" and "foreach" function exist
foreach (k in {a: 10, b: 20})
{
  // ...
}

as it will be transformed to:

// function call
foreach (k in {a: 10, b: 20})
// just a block
;{
  // ...
}

Dmitry.

Would be great if, there site with quiz like yours and @kangax

Yeah, I’m thinking on it, maybe will be soon.

Regarding semicolon insertions:

var x = true //Single line comment
false;

a) SyntaxError
b) Transform to `;false;`

var x = true /* Multi line comment
Multi line comment*/ false;

a) Syntax error
b) Transform to `;false;`

This questions are very interesting, thanks, Asen. For now I know at least two non-conformant implementations – IE (JScript) and Chrome (V8).

About the first case (ECMA-262-3, 7.4 Comments):

However, the LineTerminator at the end of the line is not considered to be part of the single-line comment; it is recognised separately by the lexical rammar and becomes part of the stream of input elements for the syntactic grammar. This point is very important, because it implies that the presence or absence of single-line comments does not affect the process of automatic semicolon insertion (7.9)

So the answer is (b) – Transform to `;false;`, as still there’s LineTerminator.

About the second case (ECMA-262-3, 7.4 Comments):

Comments behave like white space and are discarded except that, if a MultiLineComment contains a line terminator character, then the entire comment is considered to be a LineTerminator for purposes of parsing by the syntactic grammar

So the answer is also (b) – Transform to `;false;`, as again we have one LineTerminator. But IE and Chrome parse this case wrong and have SyntaxError.

Dmitry.

Seems, you can’t write in Russian, but understand English. So, sorry, I can’t write in your suggested language, and will answer in English.

From ECMA-262-3 10.1.8, bullet 2:

A property is created with name length and property attributes { DontEnum }. The initial value of this property is the number of actual parameter values supplied by the caller.

function foo(x) {
  x = 42;
  console.log(arguments.length); // 0
  console.log(arguments[0]); // undefined
  return arguments[0];
}

// number of actual
// parameter values is 0
f(); // undefined

So, in this case (no parameter passed) this property (arguments[0]) doesn’t share its value with the corresponding property of the activation object. And that’s why Chrome is wrong.

Dmitry.