Design Meeting Notes, 1/12/2018

[DanielRosenwasser]

Regex Validated Types (Cont'd)

#6579

• Real utility here is to create nominal types.
• This has utility because you get automatic type guards.
  • Will people really do this? How often does this come up?
  • You also have to rewrite the regular expression.
    • Comes up in enough places.
  • Are people going to hard-code a regex into different locations?
    • Emails? No two developers will agree what an email regex looks like.
    • CSS properties? Reasonable, but isolated.
• Also, can't have an open-ended set of strings though.
  • data-*, aria-*, Header-, etc.
• Can we split this into regex types and regex index signatures?
  • Already is split off into another proposal.
    • But need regex types to start.
      • Ehh, not totally true.
• Ability to have more specific index types is a huge request we've gotten over the years.
  • Huge change to the codebase, but would be useful!
  • Then this proposal could more-easily fall out of this proposal.
• Resolution: we don't want to commit to this until we have nominal types and generalized index signatures, and we should know what those look like.

Don't widen return types for function return types

#241

• People don't get implicit any and excess property errors for return type expressions on functions.
  • Makes people unhappy.
• We end up widening too early, before we get the chance to actually observe widening has occurred.
• Problem: we end up with issues around destructuring patterns.

  • Originally, wanted types to circle back-and-forth between default initializers in patterns as well as actual initializers. e.g.

    let { x = (abc: number) => "hello" } = { x(abc) { return "goodbye"; } }

• If you look at what default initializers in destructuring desugar to, it doesn't make much sense that the contextual typing occurs.
  • Maybe, but there's definitely an intent in mind.
• Currently we union together the LHS and the RHS in a binding pattern, but
• Out of time.

Conditional Types

#12424

type Filter<T, U> = T extends U ? T : never;
// apparently T break down to the union constituents in each branch now?

type Circle = { kind: "circle" };
type Square = { kind: "square" };
type Shape = Circle | Square;

// Desired: Circle
type Foo = Filter<Shape, { kind: "circle" }>;

type FilterShape<K> = Filter<Shape, { kind: K }>;

• Currently, we have this question about when to defer work about conditional types.
  • Starting design: if either the LHS or RHS is generic, you delay evaluation of the conditional type.
  • But what if you have an object type with a generic member?