Design Meeting Notes, 3/5/2021

[DanielRosenwasser]

Remove undefined from Optional Properties When Inferring to Index Signatutres

#43086

declare function foo<T>(obj: { [x: string]: T }): T;

declare const x1: { a: string, b: number };
declare const x2: { a: string, b: number | undefined };
declare const x3: { a: string, b?: number };
declare const x4: { a: string, b?: number | undefined };

let a1 = foo(x1); // string | number
let a2 = foo(x2); // string | number | undefined
let a3 = foo(x3); // string | number
let a4 = foo(x4); // string | number

• First two are uncontroversial.
• Second two...we effectively see those are the same.
  • Intent of last one isn't clear.
  • Need missing.
  • Half of the world's undefined is missing and half is still undefined.
• Probably fine to skew towards not including undefined.
• Reminds of "safe any"
• missing < undefined
  • ... void < undefined?
  • Can you use void?
    • Sadly no.
• Hard to guess how breaky the world would be.
  • Have to just see.
• The current "optimistic" strategy in the PR seems good. People who badly want to deal with undefined in these cases may just want --noUncheckedIndexedAccess.

Exclude enum/number compatibility rule from comparable relation

#42472

• Last design meeting notes seemed inconclusive.
• Seems like convo in issue is positive - merge.

Efficiency in Narrowing Generics

• Need to sync up on rules.
  • Makes no sense that a T extends unknown can be checked against === "foo", but a bare T with no constraint is allowed.
  • If two type parameters are distinct, and neither references the other in a constraint, then they shouldn't be comparable.
• It seems questionable that you even want an error there. Can someone defend it?
  • Can always argue that anything is fair game for ===, .includes, etc. But then you allow a big class of mistakes of relating unrelated entities.
  • Well we definitely like the number <-/-> string errors, those aren't as questionable.
  • But most generics have no constraint, so if you allowed the comparison, you could accidentally allow comparisons against the wrong thing.
• Is comparability what we use for uncalled functions?
  • No.
• Okay, what about creating intersections with generics?
  • We end up with a huge number of types in certain codebases (compilers with unions?)
  • For primitives, we can do this fast. For object types, we're very bad about it.
  • What about the discriminant checks we recently did?
    • Could potentially do that?