No compile error thrown when `this` referenced before call to `super` completes

[tomdye]

TypeScript Version:

1.8.9

Code
JSFiddle: https://jsfiddle.net/kitsonk/fs9t96ep/
TS Playground: http://goo.gl/X7cgvV

class A {
    constructor(fn: () => void) {
        fn.call(this);
    }
    foo: string = 'foo';
}

class B extends A {
    constructor() {
        super(() => {
            console.log(this);
        });
    }
    bar: string = 'bar';
}

const b = new B();

Expected behavior:
Typescript should guard against the use of this as the call to super has not completed. Thus it should not compile.

Actual behavior:
Typescript compiles this successfully. It works fine when the target is set to es5 but breaks the browser when target is set to es6.
Error is: VM89:55 Uncaught ReferenceError: this is not defined

[RyanCavanaugh]

This code isn't necessarily invalid -- it's entirely possible (i.e. we can't see its implementation) that the super constructor doesn't invoke the method immediately, in which case this would be valid to access at a later date.

[kitsonk]

@RyanCavanaugh the ES6 code:

class A {
    constructor(fn) {
        fn.call(this);
    this.foo = 'foo';
    }
}

class B extends A {
    constructor() {
        super(() => {
            console.log(this);
        });
    this.bar = 'bar';
    }
}

const b = new B();

Fails in Chrome with:

Uncaught ReferenceError: this is not defined

And in Edge:

SCRIPT5113: Use before declaration

And Firefox:

ReferenceError: |this| used uninitialized in arrow function in class constructor

It is because it is a lambda function and therefore it is trying to access the lexical this, which isn't available until after super completes, irrespective of what is actually in the super constructor. Therefore, you cannot use lambda function as arguments of a super call if they reference this in ES6 (or all 3 browser manufactures have mis-implemented the spec).

[RyanCavanaugh]

This works for me in Chrome and Edge?

class A {
    constructor(fn) {
       this.foo = 'foo';
       this.print = fn;
    }
}

class B extends A {
    constructor() {
        super(() => {
            console.log(this.bar);
        });
        this.bar = 'bar';
    }
}

const b = new B();
console.log(b.foo);
b.print();

[kitsonk]

Hmmm... wow, ok, I can break it again if I call it within the constructor:

class A {
    constructor(fn) {
       this.foo = 'foo';
       this.print = fn;
       fn();
    }
}

class B extends A {
    constructor() {
        super(() => {
            console.log(this.bar);
        });
        this.bar = 'bar';
    }
}

const b = new B();
console.log(b.foo);
b.print();

The specific use case that @tomdye and I ran into was a situation where we were extending Promise and passing in a lambda function as the executor, which gets invoked immediately. So we were going merrily along, targeting ES5 and then when we tried to target ES6, it broke.

But that is really difficult to guard against, I suspect.

[kitsonk]

@bryanforbes just suggest that given:

class B extends A {
    constructor() {
        super(() => {
            console.log(this);
        });
    }
    bar: string = 'bar';
}

If the emit was:

var B = (function (_super) {
    __extends(B, _super);
    function B() {
        var _this;
        _super.call(this, function () {
            console.log(_this);
        });
        _this = this;
        this.bar = 'bar';
    }
    return B;
}(A));

Then the runtime behaviour of ES5 would match ES6.

[RyanCavanaugh]

That seems like a good solution, though I'm slightly afraid of breaking existing working code.

[tomdye]

It will only break code that's invalid ES6 in the first place though. If they were ever to try setting the compile target to 'es6' they would see this error at runtime. Must be better to catch it at compile time now rather than down the line should they choose to compile to 'es6' at a later date.

[RyanCavanaugh]

The problem is we won't be catching at compile time -- people will upgrade to the next TypeScript version, recompile to ES5, and their code will start breaking at runtime with some very confusing errors and emit that looks like a bug.

[kitsonk]

Yes, agreed. It is clearly a breaking change, but one that preserves the runtime semantics. Maybe there is room for a linter to flag uses of lexical this within the scope of a super call (@adidahiya), since it could be uninitialized?