Closed
Description
Trailing commas on tuples
- Seems reasonable, but obviously no "omitted types" (i.e. no consecutive trailing commas)
A smarter strict signature for bind
- With
strictBindCallApply
, we have a few limitations withbind
/call
/apply
:- we only infer from the last overload.
- generic functions/methods have their type parameters erased to
{}
(or their explicit constraint).
- By-and-large, this is defensible
- But it turns out that so many of the uses of
bind
are just to bind the argument ofthis
. - What if we had a way to ignore
this
when function types don't event declare theirthis
type?- Like a new overload on
bind
?- Well you can't make an overload that fails on not specifying
this
. - But conditional types to the rescue!
- Well you can't make an overload that fails on not specifying
- Like a new overload on
bind<T, A extends any[], R>(this: (this: T, ...args: A) => R, thisArg: T): (...args: A) => R;
Could imagine a
type ExtractThis<T> = T extends (this: infer U, ...args: any[]) => any ? U : {};
type OmitThis<T> = {} extends ExtractThis<T> ? T : T extends (...args: infer A) => infer R ? (...args: A) => R : T;
interface CallableFunction {
bind<T, A extends any[], R>(this: T, thisArg: ExtractThis<T>): OmitThis<T>;
}
- Do these type parameters need constraints?
- Well,
bind
is already a method on functions, why do we need constraints? - What about the type helpers?
- Could do that.
- Will think about it.
- Well,
Handling huge type relationship checks and normalization
- Hurray for 35K lines of JSON
- You've got a ton of object literals with a
texto
and asentimento
, and a unique property with the same text astexto
. - The type-checker goes through the array literal and tries to apply subtype reduction; however, each of those unique properties makes each object type distinct, so none of them is a subtype of any other type.
- Even if we get through the extremely long subtype reduction pass, we apply a normalization pass when dealing with unions of fresh object types, so with
n
objects with unique properties, each object type is "blessed" with those unique properties being set to theundefined
type. - We have a problem where the language service just doesn't die gracefully.
- We can try to fix the problem, or we can find a way to tell users that something's going wrong.
- ¿por qué no los dos?
- We have a PR that tries to do both.
- Error on complex array literals #28707 tries to inform the user that
- >=50K failed subtype checks triggers an error on array literals
- Wesley experimented with optimizing this (Do not materialize optional
undefined
properties inside actual types #28727)- This issue tries to avoid the subtype reduction in general.
- Rather than normalizing the object types themselves, we propagate information to a flag on union types.
- Flag indicates that the union is a union of fresh or widened fresh object literals
- Fixing it seems reasonable, but it feels like you're just pushing the inevitable slightly farther away.
- Even if we were able to tell people something went wrong, it's hard to explain why things went wrong.
- We often do have some place we can provide a span on to indicate where something is going wrong.
- In Error on complex array literals #28707 you have an error that says "add an
any
here".- What do you tell a user in the JS case?
- Can we give good error messages in relationship checking?
- We tried this with giving good errors in deep instantiation checking and we had a lot of trouble here.
- We really need some sort of context stack. If we can do this, let's the error-checking in action.
- But it's not clear whether things like not doing subtype reduction are a win.
- Let's hold off on that and prefer the error message for now.