block scoped variables erroneously error on declaration order

The following example does not compile, claiming the block-scoped variables are used before declaration, which is not true. The equivalent JavaScript version executes correctly.

function foo() {
    a = 13;
    var c = b;
}

let a: number;
const b = 42;

Playground Example

Background from here:

In ECMAScript 6, let does not hoist the variable to the top of the block. If you reference a variable in a block before the let declaration for that variable is encountered, this results in a ReferenceError, because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.

and from the spec.

The equivalent JS in question:

function foo() {
    a = 13;
    var c = b;
}

let a;
const b = 42;

Quite obviously this JS never actually executes foo, so any runtime binding errors aren't found by executing it as written (unless, say, by static analysis by the TS compiler). But, say we do run this JS and then call foo(), like so:

function foo() {
    a = 13;
    var c = b;
}

let a;
const b = 42;
foo();

... it executes without error. Why is that? That is because the let a; declaration has been bound by the time we've called foo(). If you try this:

function foo() {
    a = 13;
    var c = b;
}
foo();
let a;
const b = 42;

You'll get a ReferenceError because you've attempted to access a before it was declared. Since let declarations are dependent on having been executed before being accessed, you can construct situations such as this where it is possible to initialize the binding after the apparent usage and still have that usage be valid (whoa).

Perhaps more interestingly, this means I can do this:

let a = 7;
(function() {
  foo();
  function foo() {
      console.log(a);
      return a;
  }
  let a = 2;
  foo();
})()

and the first call to foo results in a ReferenceError because the let a from the inner scope has already "blocked" a from being read until it is executed.

IMO, this is silly (I certainly see let as something that was supposed to make JS scoping more clear), but after reading over the spec one can see why it's the case.

So back to the issue at the top - is it correct for the TS compiler to error on the above? With just that snippet, nothing else involved? We can emit valid JS for that - for sure - but we would emit JS which it is possible to incur the temporal let ReferenceError error - for example, if this chunk is emitted in the middle of a set of files that get concatenated and foo gets called before let a is executed (this is valid, since function declarations are hoisted!). In isolation the TS compiler can't know if foo will be called before or after the let a and only one of those is valid runtime behavior. It's certainly safer to error and let the programmer know that this is unsafe (I know I'd want to know).

Still, in isolation the above contains no syntactical errors and the usage of let and the inner function is technically valid, if potentially unsafe.

My particular use case which demonstrated this problem had to do with namespace-level variables. I prefer to structure my code with the exported "public" symbols at the top of the namespace, and the inaccessible "private" variables at the bottom. This allows a user/reader to immediately see what can be consumed from the public API without having to wade through a bunch of implementation details.

So, it was something like the following:

namespace project {

export
class PublicClass {

    publicMethod(thing: any): void {  
        let data = extraData.get(thing);
        // do stuff with data
    }

    private _id = globalID++;
}

let globalID = 0;
const extraData = new WeakMap();

}

This is only safe because of the implementation details of TS namespaces - in effect, abusing the namespace system to guarantee safety. If your code wasn't automatically wrapped in an IIFE and executed in order by the TS emit it would be unsafe (but valid) JS. The sad truth is that when you abuse let in this manner if you had wanted to instantiate PublicClass and increment globalID in the static part of your namespace, there is the very real possibility of that being an error.

The perfectionist in me says this could go back to being a flaw in the ES6 spec for let and const - that block-level declarations can be captured by inner functions when the declaration has yet to be executed feels wrong - and against the "intuitiveness" (I declare it and it's available in all the code after it and never the code before it) that let and const are supposed to bring. In effect, the binding of a function is exempt from the block declaration "temporal deadzone".

Anyways, TS could probably add static analysis to detect when it's safe to use let like this, since it is valid sometimes? I don't particularly like that it even can be valid, myself, but that's generally what linters are for, I suppose.

Wesley Wigham (@weswigham)

As Wesley Wigham (@weswigham) explained earlier, there is not a way to know for sure if this is a runtime error or not. as it depends on execution order. We could do control flow analysis as well as alias analysis to identify cases where it would be safe to use the declaration.

Alternatively we could relax the restriction of being "syntactically declared before used", but that means we are leaving more possible runtime errors unflagged.

I think we should error on the side of allowing anything that might work. It's a temporal dead zone, not a lexical dead zone, after all. The only case we should error on is where the use occurs in the same scope (i.e. not a function body) prior to the declaration.

Mohamed Hegazy (@mhegazy)

Aye. I personally don't like that it even can work, but since it can by the JS spec it should probably be supported. But the question then becomes should we relax the requirements on let scope checking, or should we do that but also add the analysis Mohamed Hegazy (@mhegazy) mentioned to detect uses within the temporal deadzone?

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) By "same scope" do you mean lexical scope? So you won't error in this case:

{
   a = 5;
}

let a;

because they're in different scopes, even though the assignment is obviously executed in the TDZ of a ?

If you do decide to complain in that case, then how will you differentiate it from this case:

if (false) {
    a = 5;
}

let a;

where the assignment is not executed in the TDZ of a ?

I assume you'll not complain in either case.

Ryan Cavanaugh (@RyanCavanaugh)

As Ryan Cavanaugh (@RyanCavanaugh) mentioned, it is only function bodies, not block scopes. so the two cases you reference are still errors, only something like a below would be allowed.

function foo () {
    a; // No Error
}
let a;

if (false) {
    b; // still an error
}
let b;

Adding tests for #4244

If the use of the block scoped variable occurs inside function do not…

Another argument for loosening the checks (or tightening them, depending on perspective) is that this example compiles fine, when it clearly violates temporal dead zone semantics:

let f = Foo.foo;

namespace Foo {
    export const foo = 12;
}

Also, some people like to put all their functions declarations at the top, even if they reference entities declared later in the code. The strict policy makes it impossible to adhere to this style for those who prefer it. And I think it is a common enough preference.

This should be fixed now. errors are only reported within the same function if the use site is after the declaration, as it is guaranteed to fail, otherwise, no error is reported.

👍 thanks!

Navigation Menu

Repository navigation

block scoped variables erroneously error on declaration order #4244

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

block scoped variables erroneously error on declaration order #4244

Description

Activity

weswigham commented on Aug 9, 2015

sccolbert commented on Aug 9, 2015

weswigham commented on Aug 9, 2015

mhegazy commented on Aug 10, 2015

RyanCavanaugh commented on Aug 10, 2015

weswigham commented on Aug 10, 2015

Arnavion commented on Aug 12, 2015

mhegazy commented on Aug 12, 2015

sccolbert commented on Dec 22, 2015

JsonFreeman commented on Dec 22, 2015

mhegazy commented on Jan 5, 2016

sccolbert commented on Jan 5, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions