Discuss
  • Specification of use before declaration errors

Specification of use before declaration errors

# Ian Halliday (12 years ago)

I'm having difficulty figuring out where the ES6 draft spec specifies that a "use before declaration" error should be thrown. My last understanding of the temporal dead zone was that ECMAScript would always issue a "use before declaration" error at runtime, regardless whether it can be statically determined or not. However it seems like the evaluation semantics of var declarations, for example, do not lead to any line that throws a ReferenceError.

That is, consider this code:

function f() {
    {
        var x = 5;
        let x;
    }
}

f();

I think the var declaration creates a binding for x in the function's lexical environment, but then binds to the x in the block's environment for the initialization. As such, the initialization should throw a "use before declaration" error. But this is what I cannot find in the spec. Maybe I am wrong about the semantics here?

If I am not wrong then this raises the question of order of operations. Is the RHS evaluated first, then the error is thrown? Or is the LHS name evaluated first, throwing if it is a binding that is currently in its TDZ?

E.g. is g() called here before throwing?

function g() {
    console.log('hello');
    return 0;
}

function f() {
    {
        var x = g();
        let x;
    }
}

f();

How about for-in/of loops? Is g() called here?

function g() {
    console.log('hello');
    return { a: 1, b: 2, c: 3 };
}

function f() {
    {
        for (var x in g()) {
            console.log('unreachable');
        }
        let x;
    }
}
# Allen Wirfs-Brock (12 years ago)

On Nov 8, 2013, at 3:35 PM, Ian Halliday wrote:

That is, consider this code:

function f() {
    {
        var x = 5;
        let x;

declaring the same name using a let and a var is an early error: people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors or for the function level people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-early-errors

I think the var declaration creates a binding for x in the function’s lexical environment, but then binds to the x in the block’s environment for the initialization. As such, the initialization should throw a “use before declaration” error. But this is what I cannot find in the spec. Maybe I am wrong about the semantics here?

because an early error exists, the surround script or module is never evaluated.

# Ian Halliday (12 years ago)

Wait, so is there no variable shadowing allowed then?

13.1.1 Static Semantics: Early Errors

Block : { StatementList }

  •     It is a Syntax Error if the LexicallyDeclaredNames of StatementList contains any duplicate entries.

  •     It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the VarDeclaredNames of StatementList.

StatementList can contain Blocks whose LexicallyDeclaredNames and VarDeclaredNames algorithms return the values for their StatementLists, so it recursively collects the names from all nested lexical and var declarations.

It looks like VarDeclaredNames is missing a definition for VariableStatement because I can't see any way for the bound names of a VariableStatement to get added to VarDeclaredNames lists.

But barring for the moment that I cannot find an algorithm definition that adds BoundNames of a VariableStatement to VarDeclaredNames, this second early error bullet implies that shadowing of bound names is not allowed at all.

Is this correct?

# Allen Wirfs-Brock (12 years ago)

On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote:

Wait, so is there no variable shadowing allowed then?

this is saying that things like the following are illegal:

{var x; 
  let x;
}

But shadowing, like the following is fine:

var x;
{let x;
}
# Ian Halliday (12 years ago)

Then for 13.1.8 shouldn't there be something like this

StatementListItem : Statement

1. If Statement is a Block then return a new empty List.

2. Else return VarDeclaredNames of Statement

defined in order to prevent the var names from spreading into enclosing blocks?

I might be misunderstanding VarDeclaredNames. I am guessing that it should be a collection of all the names declared via var declaration statements, i.e. VariableStatement, but there isn't a definition of VarDeclaredNames for VariableStatement.

# Ian Halliday (12 years ago)

Oh, is "shadowing" a let declaration with a var declaration a syntax error? E.g.

{
    let x;
    {
        var x;
    }
}
# Allen Wirfs-Brock (12 years ago)

On Nov 13, 2013, at 4:13 PM, Ian Halliday wrote:

Then for 13.1.8 shouldn’t there be something like this

StatementListItem : Statement
1. If Statement is a Block then return a new empty List.
2. Else return VarDeclaredNames of Statement

defined in order to prevent the var names from spreading into enclosing blocks?

I might be misunderstanding VarDeclaredNames. I am guessing that it should be a collection of all the names declared via var declaration statements, i.e.VariableStatement, but there isn’t a definition of VarDeclaredNames for VariableStatement.

VarDeclaredNames are hoisted to the top level (function or script) and it is illegal to hoist a VarDeclaredName past a lexical declaration for the same named. "It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the VarDeclaredNames ofStatementList." is saying that if any name that has is immediately declared within this block cannot also occur in a var declaration either immediately in this block or in many nested block (to any level of nesting).

The hoisting is handled in the definitions of LexicallyDeclaredNames

# Allen Wirfs-Brock (12 years ago)

On Nov 13, 2013, at 4:18 PM, Ian Halliday wrote:

Oh, is “shadowing” a let declaration with a var declaration a syntax error? E.g.

yes, although strictly speaking it is the hoisting of the var over the let that is an error. Amounts to the same thing.