Skip to content

Design Meeting Notes, 4/17/2020 #38096

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

Closed
DanielRosenwasser opened this issue Apr 21, 2020 · 0 comments
Closed

Design Meeting Notes, 4/17/2020 #38096

DanielRosenwasser opened this issue Apr 21, 2020 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Inference with Promise-Likes

#37615

Worked on a heuristic when inferring to T | PromseLike<T>

let a!: Promise<number>;
let b!: Promise<string>;
let c!: Promise<number> | Promise<string>;

Promise.resolve(a); // Promise<number>
Promise.resolve(b); // Promise<string>

// Previously: error
// Now: Promise<number | string>
Promise.resolve(c);
  • In review for awaited, we realized that this sort of inference generalizes when the types are soundly covariant (i.e. covariant on )
    • But we don't track "sound covariance" right now.
    • Sounds like it's possible - could we start tracking it?
      • Could, don't have it there yet.
    • Could also do this for ReadonlyArray.
  • Still need awaited for the recursive unwrapping.
  • [[3 minute discussion on how awful JQuery's Promise type declaration is]]
  • Conclusion: let's get some reviews and get this in for 4.0 🎉

Auto-Typed Instance Properties in JS

#37900

  • In JavaScript files, we do a bunch of heuristics to figure out the types of properties on this.whatever within constructors and methods.
  • We track all the this.whatever assignments within a class and consider them assignment declarations.
    • We union all these declaration types.
      • Works, but doesn't always work; but if a property is conditionally set, we really should say "this thing is possibly undefined.
      • Also causes circularity issues when you have something like this.foo = this.foo.slice(1); or this.foo = this.foo ** 2;
  • With Control flow for constructor initialized properties #37920, we say that if a property is declared with an initializer in the constructor but no JSDoc type, it is a constructor declared property
    • In these cases, they're auto-typed and we use control flow analysis to figure out the type of each of these properties at the end of the constructor's scope.
    • Similar to what we do for let x; in --noImplicitAny.
    • Old heuristics are still around, but only when there's no assignment in the constructor.
  • We also do things like tracking when you have an auto-typed array - same stuff for let x = [] in noImplicitAny.
  • We could add this to TypeScript files as well.
  • Now you're saying if an assignment in the constructor is conditional we'll say stuff is potentially undefined - but that might mean that users get more false-positives for potentially uninitialized/undefined errors.
    • Users can add a JSDoc cast if they need.
    • Don't need a JSDoc annotation for lateinitialized or whatever yet.
  • Okay, what about doing this in TypeScript in noImplicitAny?
    • Definitely not using the old heuristic for JS - just want the constructor CFA checks.
    • As soon as you allow people to omit property types, people will ask why you can't omit the property itself.
      • As soon as you misspell an assignment in the constructor, you'd add a new declaration.
  • Conclusion: 4.0-bound, TypeScript will get auto-typed property declarations.

React's jsx and jsxs

#34547

  • Idea is that React wants JSX to be a totally opaque transform.
  • How often can this happen realistically?
    • Depends on if there's a faster behavior for everyone to ship.
  • Can just have jsx: preserve and let the bundlers take over.
    • But how do we know what the types are for JSX?
    • Using the transform sort of still implies there's an auto-import to React unless asked otherwise.
    • Even with that, you need to still have something to say "all JSX implies files are a module"
  • There's a big question mark on who does the JSX transform: is it bundlers, is it TypeScript?
    • Have to discuss, clarify what work needs to be done where.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Apr 21, 2020
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

2 participants