if first line in constructor is 'somestring', "this" is called before calling super() in constructor

[Mischi]

Hi,

we have experienced a problem where this is called before super() in a constructor function. This happen if the first line in a constructor is a string (for e.g ngInject;)

Typescript

class A  {
    blub = 6;
}


class B extends A {

  blub = 12;

  constructor() {
    'someStringForEgngInject';
    super()
  }
}

console.log(new B().blub);

and here the transpiled output

var __extends = (this && this.__extends) || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
};
var A = (function () {
    function A() {
        this.blub = 6;
    }
    return A;
})();
var B = (function (_super) {
    __extends(B, _super);
    function B() {
        'someStringForEgngInject';
        this.blub = 12;
        _super.call(this);
    }
    return B;
})(A);
console.log(new B().blub);

The transpiled output with 'someStringForEgngInject' removed works correct.

var __extends = (this && this.__extends) || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
};
var A = (function () {
    function A() {
        this.blub = 6;
    }
    return A;
})();
var B = (function (_super) {
    __extends(B, _super);
    function B() {
        _super.call(this);
        this.blub = 12;
    }
    return B;
})(A);
console.log(new B().blub);

We are using Typescript 1.7.5 and compile to ES6 which is handed of to Babel which will print a error message like this

Module build failed: SyntaxError: C:/dev/a.js: 'this' is not allowed before super()

The code for transpiling constructors probably "assumes" that the first line is always the "super" call and insert all default values in the second line?!

Issue found by @loxy, CC'ing @davidreher

Cheers,
Fabian

[sandersn]

CC: @yuit

[RyanCavanaugh]

Proposing the following behavior (@ahejlsberg, @bterlson any thoughts?)

• If super(...) is in an expression statement whose parent is a block, initializers are emitted as subsequent statements
• If super(...) is in an expression statement whose parent is a control flow statement (i.g. if (true) super()), rewrite it as a block containing a super call and its initializers
• If super(...) is in any other expression position, emit (super(...), this.prop1 = value1, this.prop2 = value2, ..., this)

[bterlson]

@RyanCavanaugh I think what you propose works.

[yuit]

As talked with @RyanCavanaugh off-line, the two bullet points should be address separately as they will involve discussing whether we should allow super call to NOT be the first statement. The fix for this issue is not related to it

[ahejlsberg]

@yuit Right, the issue here is that the checker skips prologue directives (expression statements consisting of a string literal) but the emitter doesn't. We need similar logic in the emitter where we locate the first super call.

[ahejlsberg]

@bterlson Brian, are there any proposals in TC39 to support property declarations with initializers in classes?

@RyanCavanaugh Seems like there are so many ways this could go wrong. What about situations where there are multiple super calls, e.g. in both branches of an if statement? What if the super call isn't reachable? In general I'm not super excited about changing our rules here, and if we do I think we should be very conservative.

[bterlson]

@ahejlsberg indeed, see https://github.com/jeffmo/es-class-fields-and-static-properties. Notably, "execution of the initializers happens at the end of the internal "initialization" process that occurs while executing super() in the derived constructor", which seems to align with @RyanCavanaugh's behavior. Also note the next sentence: "This means that if a derived constructor never calls super() , instance fields specified on the derived class will not be initialized".

[RyanCavanaugh]

I don't think we can realistically pick and choose which ES6 classes are valid are allowed to use property initializers based on how someone wrote the body of their semantically valid constructor.

What about situations where there are multiple super calls, e.g. in both branches of an if statement?

That's fine - we emit the initializers twice. There's nothing wrong with that. If you call super twice, it's a runtime error, so we can be guaranteed the initializers won't actually run twice.

What if the super call isn't reachable?

If the super call isn't reachable, then it doesn't matter if the initializers don't run because you can't see them anyway -- this will never be valid, and the constructor will throw at the end of execution, so you can't ever access this.someInitializedProperty to see its uninitialized value.

[davidreher]

Honestly guys: your speed is amazing! Thx for the quick help to all of you :)

[yuit]

@davidreher you're welcome :). Just an fyi, the porting to master will be done today so if you would like to give it a try on today's nightly !