Using declarations like a statement leads to strange bugs.

[olegdunkan]

🔎 Search Terms

function declaration statement

🕗 Version & Regression Information

v 5.9.3

⏯ Playground Link

https://www.typescriptlang.org/play/?target=99#code/JYMwBAFALgTgrgUwJRgG4EMZgB5gLxgAMA3ALABQAxgPYB2AztQDYIB0T1A5hNksWAHoB1ANYUKIalggsoYYPiL8FAHjABmZQGotKDFgBWi4GSp1GLdlwgGUQhDBhT5tMDQC2AB2AsAXGCNgejA4egQAEzAAIwRJGARohGBaTjB0enpgTloAGjBaajAHJyxksHhaKGB3BLA68XJQSFhEFBA4WkoqujAQCBQAbwBfCX6hAqLHZzKPbxYwKpq8qLg5YunXCsWEfwBJV3pYYC6wd2pwhJoLvPbO7oY3dFc6JgBPRLALyiZMCLS5KDUTxgFioBBMMAbTIXNLRDiUERgIA

💻 Code

if (true) var x = 0;
console.log(x); //ok

for (let i = 0; i < 3; i++) var j = i;
console.log(j) //error in compile: j is used before being assign, no error in runtime    

if (true) function f() {}
f()//no error in compile time, but error in runtime: In strict mode code, functions can only be declared at top level or inside a block 

🙁 Actual behavior

🙂 Expected behavior

Additional information about the issue

The questions above was raised only in academic purpose. I understand that there are no real use cases to apply code above.

[nmain]

for (let i = 0; i < 3; i++) var j = i;
console.log(j) //error in compile: j is used before being assign, no error in runtime    

I don't believe this is a bug. Even though var declarations are hoisted, unless the type of the variable includes undefined in it, using a var declaration before initialization is type-unsafe and warned against by Typescript. If you want to explicitly allow undefined, changing it to var j: number|undefined = i; removes the error.

The other contributing factor here is that Typescript is unable to prove that the for loop executes at least once. Not proving everything that would be provable with unlimited developer resources and unlimited compilation time is not a compiler bug.

[RyanCavanaugh]

The first one is not a bug

The second one is; now that we assume strict mode at all times, this can be a proper parse error.

[MartinJohns]

It sounds like it's a regression: #7122

[jakebailey]

now that we assume strict mode at all times, this can be a proper parse error.

We don't assume this yet. I do not think we are doing this in 6.0, only in 7.0 (if at all), so now is the wrong time to send a PR for this.

[jakebailey]

Hm, no: #54500

[RyanCavanaugh]

I also misspoke because this should be handled according to the existing strictMode logic for 6.0, since it'll be possible to turn off alwaysStrict in 6.0. 7.0 can be more aggressive.

[RyanCavanaugh]

#7122 was about the cases where you write

if (cond) {
  function foo() { }
} else {
  foo(); // legal (!) in bad mode
}

AFAICT we've never errored on if (cond) function foo() {}