Design Meeting Notes, 7/27/2018

[DanielRosenwasser]

Mapped tuple types

#25947

• Already been thinking about this a bit
• We already special-case homomorphic mapped types
  • So we can special-case tuples as well
  • But we can't special-case keyof.
  • A homomorphic mapped type already has some strange behavior.
    • For example, homomorphic mapped types know not to collapse the keys to string in the presence of a string index signature like [x: string]: SomeType.
  • Leveraging existing mapped types means you don't need to split the world into two sets of types.
• First off, in the proposal, we shouldn't change the order.
  *
• What about array-likes?
  • ReadonlyArray?
• And what does readonly from a mapped type mean operating on a tuple type.
  • Does it feel weird that readonly doesn't apply to tuple element fields?
    • "Not really, but we could make tuple fields support readonly."
• "If you run a tuple through a mapped type, you get complete garbage."
  • "It's not complete garbage"
• [[Something about index signatures that catch unknown properties]]
  • [[Tangential discussion about how you can do this with intersections]]
• Let's come back to the discussion: does all this actually solve the use-case described in the issue?

  • Could write

    all<T extends unknown[]>(...args: T): 
      Promise<{ [K in keyof T]: Unpromise<T[K]> }>;

  • Interesting to note: Unpromise is like awaited.

• Conclusion: Let's see how the PR on the current direction

null/undefined as discriminators

#24193

• We don't consider null or undefined as discriminators

• Yes we do, we just don't narrow them from properties on object types since they're not unit types.

• What you need to know is that these types have disjoint domains.

• Might add some complexity to the control flow analyzer.

  • Can't just be based on identity.

• What about in the following case?

  type ErrorOrSuccess<T> =
    | { value: null, message: string }
    | { value: T };

  • In that case, you don't know if T could be null at runtime.
  • You really need to ensure that there are disjoint domains.

• Conclusion: let's try this!

Narrowing unknown

• Two things:
  • There was narrowing based on checking for presence in properties (using in).
  • There was a request to say "I know the type in this block"
• in can potentially throw if the right side is null/undefined

  • So you can force something like

    if (x && typeof x.a === "string" && /*...*/)

• Current issue: you end up also generating new types as you narrow. We want a robust way to do this.
  • You get a gold star if you figure something out here ⭐

[mattmccutchen]

Wrong date in the title?

[RyanCavanaugh]

Nope, we just forgot to post the notes when it happened