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
Submitted a few PRs on DefinitelyTyped and ts-toolbelt
RWC has one break which is better errors
Has this PR run on material-ui in the perf test suite?
Not yet! Let's try it now.
The last thing that we found was a break in Office UI Fabric for React
When you're not in strictNullChecks, we don't add undefined to the type of optional properties.
So an intersection where a property is optional should not be considered a discriminant.
Does this only trigger for intersections where all properties are optional?
Yes.
Things to keep in mind: IteratorResult uses undefined as a discriminant
Is a break
But found a lot of better behavior
Lots of people doing & to create filters.
Intersections used to produce absolute garbage for discriminated unions - now we correctly filter them down.
Wait, why is there a different error baseline for some mapped type thing in the PR?
New change we've wanted to do for a long time.
Today, when we resolve the members of a mapped type, we also decide to instantiate each of their respective types.
But now diving into intersections means that we need to probe a little bit deeper to figure out if it needs to reduce, but that can trigger some circularities in exploring types.
A test in Redux ORM test had a bunch of issues in inference because of recursive types - doing the intersection reduction cause circularity issues, this deferral on mapped type property types fixes this.
Helps material-ui by 10%, though the intersection work offsets this a bit.
What about a carve-out from objects in expression positions? Things that come from object literals are awaited to themselves, anything else becomes something else.
await on Promise<object> already gives you object
Also, Promise<object> such that the dynamic/runtype type of the object is a Promise can never exist on an A+ Promise - so this is rare in practice.
Promise<Promise<number>>can and does happen accidentally. #35998 accommodates these accidents in more but not all contexts: Full support would mean making Promise<Promise<number>> assignable to Promise<number> which is an even bigger change than adding a new kind of type? Meanwhile better partial support will encourage more bugs like this, because they are tolerated in more but not all contexts.
An advantage of not supporting nested promises is that it doesn't require a new kind of type.
The reason to introduce a new kind of type, besides accommodating accidentally nested promises, is to support non-A+-compliant promises as in jQuery 2. I have very little context but haven't seen any demand for better support for non-A+-compliant promises. I'm skeptical that adding a new kind of type for this is justified?
Update on Collapsing Intersections of Impossible Discriminated Unions
#36696
never
sstrictNullChecks
, we don't addundefined
to the type of optional properties.IteratorResult
usesundefined
as a discriminant&
to create filters.Update on
awaited
#35998
Looking to reintroduce the
awaited
typeHeld off on this because people wanted to do recursive digging on any type
We had a ton of PR s to fix up
Promise.all
,Promise.race
, etc.Have one assignability rule that's not sound but is useful:
awaited S
relates toawaited T
ifS
relates toT
then()
method.awaited object
unknown
?awaited {}
?{}
null
orundefined
!awaited {} -> {}
feels okayish,awaited object -> object
feels wrongWhat about a carve-out from objects in expression positions? Things that come from object literals are
awaited
to themselves, anything else becomes something else.await
onPromise<object>
already gives youobject
Promise<object>
such that the dynamic/runtype type of theobject
is aPromise
can never exist on an A+ Promise - so this is rare in practice.Some other stuff seems broken.
object
is so useless - but what is the distinguishing factor betweenobject
andPoint
andBox
?Wasn't
object
was always broken? Maybe it doesn't matter what happens here.object
or{}
]]We just need to acknowledge where the type holes are.
What about the breaks from
awaited T
not being assignable toT
?Again, is this a necessary break? You can almost never construct a
Promise<...>
in place ofT
, so you could never end up withPromise<Promise<T>>
.So what are we feeling?
awaited Promise<object>
->object
: yesawaited object
->object
: No?unknown
?object
and intend for it to bePromise
? That's practically never the intent.Joke: what about
T extends nonpromise
?What about conditionals?
awaited (T extends Foo ? T : Promise<T>)
assignable to(T extends Foo ? T : Promise<T>)
.Conclusion
downlevel-dts
Optional Chaining and Non-Null Assertions
#36539
!
in the middle of a chain is a chain,!
at the end is not.Update on CommonJS Emit for Exports
#37093
export *
when a module overrides exports from anexport *
.undefined
so that our__exportStar
helper doesn't try to trample over the properties with getters.The text was updated successfully, but these errors were encountered: