You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sounds like you want #5863, but if I recall correctly, the problem is that we don't assume the static side of one class is substitutable for another because then every subclass construct signature would have to be assignable to the constructor in the superclass.
Actually that bit is handled fine via the option useDefineForClassFields. The badness comes from using this at top-level scope. The downlevel is just semantically wrong.
Interestingly this bug goes away if target == ESnext && useDefineForClassFields == true.
We should remove the error for useDefineForClassFields+ESNext. The emit is correct and the type is correct. So the error is wrong there.
For class field emit, we could just replace this with C outside function and class expressions in static property initialisers. In that case we could remove the error entirely.
I thought that this emit would be incorrect with the semantics proposed in Polymorphic "this" for static members #5863, but that issue requests a thistype for the static side of the class. Right now, in a static property of C, this: typeof C, but the emit wouldn't need to change if we changed it to be this: this.
Have we considered changing our downlevel emit to support this case? We could either replace this with the class name depending on the context, or just wrap static initializers in something like:
(function() {
Foo.t = this;
Foo.at = () => this;
}).call(Foo);
Not necessary for this PR, but some food for thought.
Activity
DanielRosenwasser commentedon Jan 17, 2020
Sounds like you want #5863, but if I recall correctly, the problem is that we don't assume the static side of one class is substitutable for another because then every subclass construct signature would have to be assignable to the constructor in the superclass.
rauschma commentedon Jan 17, 2020
AFAICT, this is simpler. In first example above,
thisis just a synonym forC.Another example:
DanielRosenwasser commentedon Jan 17, 2020
So you want "Monomorphic
thisfor static members" 😄rauschma commentedon Jan 17, 2020
Probably? 🤔
robpalme commentedon Jan 19, 2020
Thank you for finding this Axel Rauschmayer (@rauschma)!
It's not just the type checking that's wrong. The emit is corrupting legit ESnext code. Playground
...becomes...
rauschma commentedon Jan 19, 2020
Right! Should be done via definition, not assignment.
robpalme commentedon Jan 19, 2020
Actually that bit is handled fine via the option
useDefineForClassFields. The badness comes from usingthisat top-level scope. The downlevel is just semantically wrong.Interestingly this bug goes away if
target == ESnext && useDefineForClassFields == true.RyanCavanaugh commentedon Jan 21, 2020
Nathan Shively-Sanders (@sandersn) can you look at the emit thing (described lower in comments) ?
sandersn commentedon Jan 22, 2020
Note that the classic, non-spec-compliant emit has been wrong since at least 2.4: https://www.typescriptlang.org/play/?ts=2.4.1#code/MYGwhgzhAEDCD2J4CdoFMAeAXNA7AJjAKK4CuAtgJYBmAntAN4CwAUNNBFmFpcNMmnzQAvNFxoA7nEQoAFAEoA3K3aduvaCjC4A5mhFjJ0pMgXK2HLjz600IJFNHipCE2ZWX1fHQLwHnxnJKHmrW0ABGIKT6TkauQeaqVhoADqTIKSAxhi4ypsEWoRoA+gZYABaUEAB0oPAQaCQUZtAA9K3QACq0KWgAysDIlClYAFyByLVIDU3kCqwAvkA
sandersn commentedon Feb 13, 2020
thiswithCoutside function and class expressions in static property initialisers. In that case we could remove the error entirely.thistype for the static side of the class. Right now, in a static property ofC,this: typeof C, but the emit wouldn't need to change if we changed it to bethis: this.I did (1) in #36781.
Ron Buckton (@rbuckton) can you think of any problems with changing
thisreferences toCwhen emitting static properties?7 remaining items
Kingwl commentedon Mar 5, 2021
Any progress?
It's affect #42986 and #43092 at least.
from #36781 (review)
It's might good for now.