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
Background: If you have a decorator on a class field that tries to replace it with an accessor, that only works under UDFCF (i.e [[Set]] semantics), it breaks under ES [[Define]] semantics
Most decorators assume [[Set]] semantics
Most people, rightly, don't know/care the difference
Using latest always seems nice! But this breaks your decorators
We changed UDFCF to true in ES2022 in 4.2
Our explanation of why you got broke is very logical and correct, but it still sucks and no one can figure out why, plus there are no guardrails
NonNullable today is a conditional type, which has many drawbacks
Ideally it could just be type NonNullable<T> = T & { }
(Read the PR notes)
Interesting cases in generics involve exclusions, either via else or !==
if (x !== undefined) { const x1 = x } else { const x2 = x }
x2 gets T when it could be T & undefined, but this means the CFA join points produce types like T & {} | T & null | T & undefined and require a new unification rule to convert that back to T
Other potential further work involves e.g. if (x === 'a' || x == 'b') { could narrow to T & 'a' | T & 'b'
useDefineForClassFields
under ES2022[[Set]]
semantics), it breaks under ES[[Define]]
semantics[[Set]]
semanticstrue
inES2022
in 4.2experimentalDecorators
(ED) + UDFCF[[Define]]
semanticstarget: es2022
must imply UDFCFdefineProperty
inobserve
here is not an intended use of experimental decoratorsaccessor
keyword, which is in the Stage 3 proposal, and let people fix themselvesdeclare
keyword. User education problem.experimentalDecorators
🧪, and we didn't move thetarget
ourselves - this is "the user's fault" to the best degree that it can bemobx
uses this pattern and the "misuse" described above seems extremely commondeclare
and fix this? A: Yes, but no one reads the docsunknown
and unconstrained type parametersNonNullable
today is a conditional type, which has many drawbackstype NonNullable<T> = T & { }
else
or!==
if (x !== undefined) { const x1 = x } else { const x2 = x }
x2
getsT
when it could beT & undefined
, but this means the CFA join points produce types likeT & {} | T & null | T & undefined
and require a new unification rule to convert that back toT
if (x === 'a' || x == 'b') {
could narrow toT & 'a' | T & 'b'
{}
now narrows toobject
viatypeof === 'object'
extends object
#48468 is successfully mitigatedNonNullable = T & { }
?function c<T extends string | number, U extends number | boolean>(x: T & U) {
x
should benumber
but we don't have logic to do thatThe text was updated successfully, but these errors were encountered: