Skip to content

Design Meeting Notes, 3/5/2021 #43146

Closed
Closed
@DanielRosenwasser

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions