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/5/2021 #43146

Closed
DanielRosenwasser opened this issue Mar 8, 2021 · 0 comments
Closed

Design Meeting Notes, 3/5/2021 #43146

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

Comments

@DanielRosenwasser
Copy link
Member

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?
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Mar 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant