Suggestion Backlog Slog, 11/27/2017

[RyanCavanaugh]

• Relax the rule on the compiler side that all declarations have the same constraint #20018 Remove restriction that all type parameters redeclare the same constraint
• Suggestion: option to include undefined in index signatures #13778 Include undefined in index signatures
• No warning when using unary +/- operators on functions and objects? #20131 Tighten unary + and/or -
• Granular inference for generic function type arguments #20122 Some kind of change to generic type inference
• Optional Generic Type Inference #14400 Optional generic type inference
• unknown: less-permissive alternative to any #10715 unknown a.k.a. mixed - refinable version of {} | null | undefined
• Allow type annotation on catch clause variable #20024 Allow arbitrary type annotations (or as clauses?) on catch clauses
• Allow to call getter/setter logic When subclassing #338 Allow calling base class getters/setters
• Treating undefined parameters as optional #12400 Allow skipping parameters that accept undefined

[RyanCavanaugh]

• Relax the rule on the compiler side that all declarations have the same constraint #20018 Remove restriction that all type parameters redeclare the same constraint
  • Creates tons of breaking changes for no reason
  • 👍
• Suggestion: option to include undefined in index signatures #13778 Include undefined in index signatures
  • Would this go under --strict ?
    • Initial impression is no
    • Some people like it assuming length checks are in
    • Why not?
  • Do we need separate options for numeric and string index signatures in this world?
  • Do we add undefined to shift and pop?
    • Yes
  • Sidebar: Kvetching about the Playground /cc @DanielRosenwasser
    • Use a nightly build
    • Serialize settings in the Share URL
    • Add an error list
  • What does this do?
    • Only affects the read side, not the write side
    • a[i] = a[i]; is an error now 😱
  • What's it called?
    • ...unprintable
  • Proposal is no different from how we treat properties in union types
  • Could we add a specific guard for x < arr.length + arr[x]?
    • Would make this pretty palatable
    • Machinery is in place for this because of for .. in
    • Standard for loops would work
    • Backwards for loops are terrible
    • Is an unsound version of this what people want?
      • What about negative indexes?
      • What about mid-loop mutation?
  • We've never had a problem here... are we special / too smart? The latter is unlikely, at least
  • Easier version: TSLint rule that forces ! after all array index access?
  • Move on
• No warning when using unary +/- operators on functions and objects? #20131 Tighten unary + and/or -
  • +date is a common idiom that needs to be left alone
  • Save for a revamp of the entire implicit numeric coercion story with Date in mind (e.g. > and < which are currently allowing objects, wat?)
• unknown: less-permissive alternative to any #10715 unknown a.k.a. mixed - variant of {} | null | undefined
  • What's the request?
    • "Level 1": Simle type alias for {} | null | undefined
    • "Level 2": Type-guardable (comes for free with level 1)
    • "Level 3": Allows implicit creation of properties through type guards
  • Would hopefully remove a lot of confusion from DefinitelyTyped
  • Think more about it
• Allow type annotation on catch clause variable #20024 Allow arbitrary type annotations (or as clauses?) on catch clauses
  • Fun fact: you can throw null or throw undefined
  • Anything we let you write here would be a lie
  • Back to AMF
• Allow to call getter/setter logic When subclassing #338 Allow calling base class getters/setters
  • The emit is so ugly 😿
  • Vanishing problem due to ES6 adoption
  • Won't Fix
• Treating undefined parameters as optional #12400 Allow skipping parameters that accept undefined
  • Big impact on generic type inference
  • Sidebar: Should we change the result of 0-candidate generic type inference? {} is manifestly wrong in SNC
  • 👍
• Out of time
  • Granular inference for generic function type arguments #20122 Some kind of change to generic type inference
  • Optional Generic Type Inference #14400 Optional generic type inference