Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 12/7/2018 #28908

Closed
DanielRosenwasser opened this issue Dec 7, 2018 · 0 comments
Closed

Design Meeting Notes, 12/7/2018 #28908

DanielRosenwasser opened this issue Dec 7, 2018 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Trailing commas on tuples

#28893

  • Seems reasonable, but obviously no "omitted types" (i.e. no consecutive trailing commas)

A smarter strict signature for bind

#28900

  • With strictBindCallApply, we have a few limitations with bind/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 of this.
  • What if we had a way to ignore this when function types don't event declare their this 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!
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.

Handling huge type relationship checks and normalization

#28540

  • Hurray for 35K lines of JSON
  • You've got a ton of object literals with a texto and a sentimento, and a unique property with the same text as texto.
  • 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 the undefined 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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Dec 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant