parameter initializer is bound to the wrong variable

[ajafff]

TypeScript Version: 2.8.0-dev.20180321

Search Terms:

Code

let foo = 1;

(function (bar = foo) { // unexpected compiler error; works at runtime
    var foo = 2;
    return bar; // returns 1
})();

(function (bar = (baz = foo) => baz) { // unexpected compiler error; works at runtime
    var foo = 2;
    return bar(); // returns 1
})();

(function (bar = foo, foo = 2) { // correct compiler error, error at runtime
    return bar;
})();

Expected behavior:
No error on the first and second function expressions
This used to work in a previous release.

Actual behavior:
Compiler error on the first two function declarations even though the code works at runtime.

Initializer of parameter 'bar' cannot reference identifier 'foo' declared after it.

Variable 'foo' is used before being assigned.

Playground Link:

Related Issues:

[mhegazy]

Compiler error on the first two function declarations even though the code works at runtime.

The code as emitted by the TS compiler will not work. the first example for instance will result in bar having the value undefined and not 1.

To generate code that would work, the compiler will have to do the initialization in a function scope other than the function itself, effectively warping the function in an IIFE.

We choose a while back to not do that as it impacts the readability of the generated code, and instead we opted in adding an error instead.

This used to work in a previous release.

I do not think this ever worked. I went back to 1.8 and the same errors are reported.

[ajafff]

@mhegazy

The code as emitted by the TS compiler will not work. the first example for instance will result in bar having the value undefined and not 1.

That's only true if the target is ES3 or ES5. I'm currently targeting ES2015.

To generate code that would work, the compiler will have to do the initialization in a function scope other than the function itself, effectively warping the function in an IIFE.

Or you could rename all function scoped identifiers (that are used somewhere in parameter initializers) that shadow declarations outside of the function. (cc @rbuckton)
You already do similar renames for lexical declarations:

// foo.ts
var foo = 1;
{
    let foo = 2;
}

// foo.js
var foo = 1;
{
    var foo_1 = 2;
}

/**********************/

// fn.ts
let foo = 1;

(function (bar = foo) { // unexpected compiler error; works at runtime
    var foo = 2;
    return bar;
})();

// fn.js
var foo = 1;
(function (bar) {
    if (bar === void 0) { bar = foo; }
    var foo_1 = 2;
    return bar; // returns 1
})();

We choose a while back to not do that as it impacts the readability of the generated code, and instead we opted in adding an error instead.

May I ask you to reconsider this decision?

I find this rather concerning as it only applies to code transpiled to ES3 and ES5. It makes using ES2015 features difficult to use because it shows errors that are technically not correct. If I didn't know much ES2015 I would think that it's not possible at all as I assume TypeScript does the correct thing.

You also use this same implementation to power the JS language service which doesn't show errors by default. As a user I'm really confused when "Go to declaration" jumps to a different variable than what's used at runtime.

[RyanCavanaugh]

Or you could rename all function scoped identifiers (that are used somewhere in parameter initializers) that shadow declarations outside of the function.

In the general case, we can't know what other outside variables in scope might exist.

[mhegazy]

That's only true if the target is ES3 or ES5. I'm currently targeting ES2015.

We can disable the whole check if we are in ES2015 or higher.

[mhegazy]

feel free to send us a PR for disabling the check for ES2015 or later.

[ajafff]

Unfortunately it's not only the error message. The whole name lookup needs to be changed to make this work as expected.

[mhegazy]

U are right, we can change that too.

[mhegazy]

one concern i have is that the semantics of the same code snippet would be different based on your target compilation..