Closed
Description
This is valid, but seem very dangerous:
class One {
two() {};
}
class Foo {
two = this.one.two();
one = new One();
}
The emit goes in order of declaration which will cause a runtime error:
var One = (function () {
function One() {
}
One.prototype.two = function () { };
;
return One;
})();
var Foo = (function () {
function Foo() {
this.two = this.one.two();
this.one = new One();
}
return Foo;
})();
Activity
kitsonk commentedon Dec 30, 2015
I suspect this got lost in the pile. Any thoughts, or is it just and edge case that isn't worth bothering with?
DanielRosenwasser commentedon Dec 30, 2015
Sorry about that, this past month's been busy and naturally some people are out.
I wonder if this should fall under the umbrella of #2234.
[-]Dangerous Parameter Initializers in Classes[/-][+]Dangerous Property Initializers in Classes[/+]kitsonk commentedon Dec 30, 2015
Clearly it is related to #2234, but I would suspect a lot of users would be "surprised" that they have to think about the ordering of a property initializers in a class, although I just checked the ES Stage 1 proposal for class properties and initializers and it appears that this would break there too, so the emit is valid. In that case, stupid is as stupid does and it would logically fall in the realm of use before initialization.
cc/@adidahiya
RyanCavanaugh commentedon Jan 1, 2016
"Order of emit is order of declaration" is a must-have behavior for
ES6 compatES7+ compat as that would almost certainly have the same semantics.I don't see why we wouldn't error here, though. We can treat these as if they were
let
declarations in terms of TDZ rules.theseyi commentedon Mar 15, 2018
Is this a similar issue to the ffg being allowed in TS?
I can't find any documentation that says you can reference this in a class field / property but TS allows this to compile and emits js, but looking at it seems odd.
emit:
http://www.typescriptlang.org/play/index.html#src=class%20Test%20%7B%0A%20%20x%3Aany%20%3D%20this.x%3B%0A%7D
theseyi commentedon Mar 16, 2018
@kitsonk Thoughts?
kitsonk commentedon Mar 22, 2018
I don't know if it is similar. It is valid, though illogical. My opinion would be that it should be an error as well (sort of the same class as use before assigned).
JoshuaKGoldberg commentedon Jan 12, 2019
The original code now correctly gives a type checking error! ✨
However,
x: any = this.x;
is still allowed but shouldn't be.Added error for class properties used within their own declaration
6 remaining items