Suggestion: execute property initializer expressions at the expected time

[elibarzilay]

Currently, TS moves property initializers in a way that can be suprising and lead to subtle problems. Eg, Issue #7644, but I've seen it in other places. Another example which I ran into in a PL class (while trying to demonstrate something else...):

let y = 1;
class Foo {
    private x = y;
    constructor(y) {
    }
}

The error message for this is confusing, but IMO it is expected since it's the behavior of these things that is confusing. That's a result of moving the expressions into a different scope than the original source and also a different time (in the constructor call instead of when the class is generated).

So I think that it would be much better (and solve a bunch of issues around this area) if the emitted code would evaluate the initializer expressions at a proper time, for example, producing this code for the above:

var y = 1;
var Foo = (function () {
    var _y_init = y;
    function Foo(y) {
        this.x = _y_init;
    }
    return Foo;
}());

I'm gussing that (some of) the reasons to not do that are being able to refer to this in these expressions, and the fact that you get values that are shared for all instances (eg, with a private x = {} initializer). Personally, I'd argue that neither of these is worth keeping: before I dug into this I assumed that a {} value would be shared, and I never considered using this. on the RHS, since I automatically didn't assume that there exists one that can be used.

But assuming that it's hopeless to fix this completely (since it'd break code in subtle and potentially disastrous ways), so the unexpected (for me) execution order must stick. But the scope breakage is more subtle and more important, so how about fixing just that with something like:

var y = 1;
var Foo = (function () {
    function _init(_this) {
        _this.x = y;
    }
    function Foo(y) {
        _init(this);
    }
    return Foo;
}());

And it would be nice if such an _init thing is consistently done after a super() when there is one, since the time when these expressions are evaluated is changed anyway, there's no reason for people to expect them to happen before a super (and such an expectation now is unreliable since the initialization happens, AFAICT, either before or after a super).

[elibarzilay]

(Ugh, the subject should change from "at the expected time" to "in the expected scope".)

[RyanCavanaugh]

What's an example where initialization happens before super when there are zero compile-time errors?

[mhegazy]

Worth to note that this proposal is inline with the semantics as outlined by TC39 proposal in https://github.com/jeffmo/es-class-fields-and-static-properties.