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, 3/9/2018 #22445

Closed
DanielRosenwasser opened this issue Mar 9, 2018 · 0 comments
Closed

Design Meeting Notes, 3/9/2018 #22445

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

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Mar 9, 2018

Narrowing & Combining Higher Order Types

#20673
#21369
#15100

#22096

#21182
#15643
#19469
#14967
#15376
#18902

  • We've been somewhat inconsistent about narrowing.
    • "Well, we're consistent, but we don't narrow constraints."
    • But sometimes we do intersections, sometimes we narrow unions, etc.

Today:

function f<T>(x: T) {
    if (typeof x === "string") {
        // 1: 'x' has type 'T & string' here.
    }

    if (x != null) {
        // 2: nothing happens here
    }
}
  • At 1, treating this as an intersection here is likely correct.
    • But the problem is that we're not sure that, when performing instantiation, you really want to absorb more general types to their more derived types (e.g. number & 100 becomes 100) because this can affect contextual types, etc.
      • It seems like it's ostensibly okay for intersections; not necessarily for unions.
        • You are strictly losing types from unions.
  • At 2, you want to find a way to remove null and undefined.
  • Conclusion: not a 2.8-bound change, but let's experiment with using the user-land type operators.

Should we allow indexed access types on nullable

#14366

  • Current PR allows you to access any branch in a union.
  • Currently, you'll get different behavior if you index into a generic type parameter vs. its instantiation.
    • Well, yeah.
  • Maybe we should just give people a ! type operator since that's what people originally asked for.
  • Conclusion?
    • We have a solution now anyway; less change in the type system itself is more desirable.
    • Hold off.

Type imports at arbitrary locations

#14844

// import * as _foo from "./foo";
// let x: typeof _foo;
let x: import("./foo");

// import { Foo } from "./foo";
// let y: Foo;
let y: import("./foo").Foo;
  • What about confusion with the import operator that returns a Promise?
    • Probably not that confusing.
  • What about esModuleInterop.
    • Sounds like you're doomed to the same problems.
      • import("foo").default for export = .

JSDoc type imports

#22160

  • Just have people use typedefs with the new syntax.
/**
 * @typedef {import("foo").default}
 */
  • Hold off on any new syntax.

Generics in JSX

#22415

  • Parsing is fine.
  • Let's do this.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant