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
Currently this doesn't work well - when we get the contextual type for x, we get it from the erased signature of <T>(a: T) => { value: T[] }, which is really just (a: any) => { value: any[] }.
We will have a PR that will help fix this.
Q: What about constraints?
A: Constraints will be carried through.
We will still have some problems with compositional patterns without explicit types.
For example:
The problem is that TypeScript draws the following inferences:
Type Parameter
Inferences
A
U
B
U[], T
C
{ value: T }
The way we walk through arguments (simple and left-to-right) and draw inferences simply isn't sufficient - we need to find a way to unify these type parameters.
But it's not just a matter of throwing unification at the type system. So the current question is how do we introduce some unification to the current process. Perhaps it will be a "last resort" process. And this will be exploratory work.
@gcnew did do great work, but pointed out many of the difficulties and roadblocks you can run into.
Changing default target to ES5
Very strange that we wouldn't simply move the the higher one?
Why take a breaking change when we'll need to make another breaking change in the future?
Are there a lot of people running into this problem?
Doesn't appear that a lot of people have been complaining about it.
Pure annotation in downlevel emits
Currently, Uglify doesn't understand when our class emit.
It would be great if Uglify could operate on the ES2015 code.
We just want to tell other tools it's a class - onus of determining side-effects being on TypeScript is probably more questionable than an optimizer doing so.
Propagated Inference for Uninstantiated (Free) Type Parameters (#9366)
Currently this works.
Now we ask, what if we wanted
boxElements
to operate on any type?Currently this doesn't work well - when we get the contextual type for
x
, we get it from the erased signature of<T>(a: T) => { value: T[] }
, which is really just(a: any) => { value: any[] }
.We will have a PR that will help fix this.
Q: What about constraints?
A: Constraints will be carried through.
We will still have some problems with compositional patterns without explicit types.
For example:
The problem is that TypeScript draws the following inferences:
A
U
B
U[]
,T
C
{ value: T }
The way we walk through arguments (simple and left-to-right) and draw inferences simply isn't sufficient - we need to find a way to unify these type parameters.
But it's not just a matter of throwing unification at the type system. So the current question is how do we introduce some unification to the current process. Perhaps it will be a "last resort" process. And this will be exploratory work.
@gcnew did do great work, but pointed out many of the difficulties and roadblocks you can run into.
Changing default target to ES5
Pure annotation in downlevel emits
@class
comment unconditionally.Lib reference directive (#15780)
/// <reference lib="name" />
Problem: things like corejs on DefinitelyTyped conflict with compiler defaults.
This means could simply be reduced to
/// <reference lib="es2015.d.ts" />
.Q: What about
/// <reference no-default-lib="true"/>
?/// <reference no-default-lib="true"/>
comments.Could also do
/// <reference lib="..." />
inlib.d.ts
as well.What about Daniel's lib versioning idea of publishing to
@types
?node.d.ts
in.The text was updated successfully, but these errors were encountered: