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, 12/9/2020 #41907

Closed
DanielRosenwasser opened this issue Dec 10, 2020 · 0 comments
Closed

Design Meeting Notes, 12/9/2020 #41907

DanielRosenwasser opened this issue Dec 10, 2020 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Infer Template Literal Types from Template Expressions

#41891

  • Up until this PR, whenever you'd write a template literal expression, we'd just infer string.
  • With this PR, we always give a template literal type to these expressions.
  • We now have a widening and non-widening form.
    • Non-widening form is "fresh", widens to string once it flows into a mutable location.
    • So const preserves the literal-ness, while let enforces a widening
  • Weird issue - template literal types didn't consistently have a string constraint, so werent assignable to other top-level types.
  • Side note: don't waste time on Node 8.
  • If you infer `hello${string}world` from `hello${foo}world`, does that mean you're expecting at least one character in the middle?
    • No, only applies to consecutive generics with no delimiter, e.g. `hello${T}${U}world` where T and U both extend string.
  • This is a breaking change because we used to always widen the results of a function to return string.
  • In the return type of a function, we return the non-widening variant, right?
    • Correct.

Optional Property Checking Against Index Signatures

#41418
#41505

  • When we have spreads with optional properties, we don't correctly mix in undefined.

    declare let r: { [key: string]: number };
    
    declare let fromAnnotation: { x?: number };
    r = { ...fromAnnotation }; // Error: Type 'undefined' is not assignable to type 'number'.
    
    let fromExpression = { ...!!true ? { x: 3 } : {} };
    r = { ...fromExpression }; // Ok
  • Also discussed allowing properties with undefined to be assignable to an index signature.

    • Likely can't truly fix index signatures to always implicitly produce undefined because of arrays.
    • We could do this just for string index signatures.
  • With the string index signature behavior permitting undefined properties, how does this extend to our "generalized key types"?

    • Would imagine that it does extend correctly.
  • What about delete?

  • What's the mechanism for this? Some higher-order thing?

    • No, strip out undefined from the property before the check.
  • Is it weird to make an exception for numeric index signatures?

    • Probably doesn't matter.

    • Totally matters

      const tuple = [undefined, 2, 3] as const;
      var arr: number[] = tuple; // make sure this still errors
  • Is there a way to track whether these were optional to begin with? And only do the check then?

    • A more limited change, and you can't take back the behavior as easily if you always allow undefined.

      declare let fromAnnotation2: { x: number | undefined };
      // Error: Type 'undefined' is not assignable to type 'number'.
      declare let r: { [key: string]: number } = { ...fromAnnotation2 };
  • Conclusion: try this with just optional properties.

    • The magic happens in indexTypesRelatedTo with eachPropertyRelatedTo.

Option to Use unknown in try/catch Variable Types

#41013

  • Why is it not a strict flag?
    • It's not, but it could be.
    • Feel like taking a slower approach on this is okay.
  • But that's the point of strict, getting better checks, right?
  • If you have noImplicitAny, is that an error today?
    • Probably good support for the idea that this should be a strict mode flag.
  • Maybe this should just be under noImplicitAny.
  • The philosophy of strict is being open to being broken as soon as we get better.
  • Gaping hole in the product that nobody has really paid attention to.
  • Maybe we should have an easy : any quick fix.
  • Conclusion
    • Workshop name
    • See what breaks under strict
    • Quick fix

Remove Special any Assignability Exception from Numeric Index Signatures

#41660

  • How did it make sense before?
    • Well, it sorta didn't.
    • Numeric index signatures are supposed to map a subset of string properties.
  • This breaks transitivity.
    • Wait, no, it's fine.
  • Hearkens back to the "dense vs. sparse" conversation in the first topic.
    • Having no numeric properties means that you should be compatible technically!
  • In line with the original change.
  • What breaks?
    • Test based on Mithril
    • Office UI Fabric
    • RxJS (but in a good way)
  • Anecdote: we have a tendency to say "oh my gosh, what's a user supposed to do?", but when outside the team, we would take the time to fix correctness issues and we'd be better off doing it.
  • Historically, with issues like this, how helpful have we found the release notes to be helpful?
    • Mixed bag, but it does help a lot of people.
  • Original scenario is compelling; what about an alternative approach.
  • Implemented object type a while back - might want to create a function type?
    • Opposite use-case, doesn't help here.
  • Conclusion: evaluate what the fixes feel like on the codebase.
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