Suggestion Backlog Slog, 10/1/2020

[andrewbranch]

• Expected at least x arguments, but got x or more #28010 Spread with leading widened array gives nonsense error message when it shouldn't even error
  • A fix implies having a leading or mid-span rest in a tuple type (e.g. [number, ...string, number])
  • Can we just fix this? ("fix" being allow these calls, not capture 'a' as a 1-tuple)
    • This example "works" because the types of the parameters match, but that's a bit of a special case - this call can only succeed if they match (or are related)
  • The second arg here gets "lost" into a's variable-lengthness
  • At a minimum we should make the error not be nonsense
  • How would you efficiently reason about a call like
    • foo(a: number, b: number, c: number, ...more: number[])
    • foo(...arr, 1, 2, 3)
    • Don't you have to evaluate this as all possible array arities?
  • Not tractable with current mechanics; advise people not to use this form
  • Upvotes are probably from prior behavior that was much worse
  • Conclusion: Issue an error on the spread: expected a fixed argument, but got a variable-length spread (workshop this)
    • Do this whenever a variable-length array is spread into a non-variable parameter position
• Fall back on default type parameter when inference does not yield a more suitable type #16229 Going back to the default type parameter value
  • Behavior is very much intentional
  • Close WAI
• Easier destructuring with type annotations on binding patterns #29526 Intermix syntax of destructuring and type annotations
  • No good options and none have been found, should we just do something we know isn't great?
  • :: is part of a proposal called "guards"; avoid this
  • This syntax is already very confusing
  • as ?
    • It's not a cast.
  • Someone wrote a good summary of options
    • They're all subjectively awful
  • The cure seems worse than the disease
  • Don flamesuit, close
  • What if there were a syntactic prefix that said "Colons in this are types, not renames" ?
    • e.g. function fn(%{ a: string, b: number })
    • Still bad
• Suggestion: add excludeTypeRoots to tsconfig #18588 excludeTypes
  • Most people misapprehend this, e.g. they want forceExclude, not a simple filter
  • The real request here is that people don't want infectious @types/node, excludeTypes will not fix this
  • types: [] is a good default in modern TS
  • Close, say types: [] in your tsconfig because if that didn't fix your problem, then this wouldn't either
  • Clarify that you only need to types: those that wouldn't get into your program via an import anyway
• Add a --strictNaNChecks option, and a NaN / integer / float type to avoid runtime NaN errors #28682 NaN typing
  • If exists, wouldn't we have to put it literally everywhere?
  • If NaN exists, is it a subtype of number ?
    • If yes, then number | NaN is an evaporating union to number, and this never does anything useful
    • If no, then... maybe that works?
  • Almost every operation could yield a NaN, but very few of them do under reasonable arguments except in cases where people are already on guard
  • Insufficient merits compared to complexity
• Extending string-based enums #17592 Spreading string enums
  • extends is the wrong syntax since it doesn't create a subtype; ... is better
  • Upvote count is bafflingly high
  • Would only operate on string enums
  • Does this create a new type with mixed members, or are these members differentiated from their base definitions?
    • AdvEvents.Start and BasicEvents.Start are identical; both refer to the same type
  • This is pretty different from how string enums work today
  • It's actually a new kind of string enum; it doesn't behave the same as its naive desugaring

[fleck]

Hello, with regards to destructuring type annotations. Do you have a link to the "guards" proposal? I looked around on TC 39 but couldn't find it. If the double colon is a no go can we come up with another usable token? Almost anything would be better than having to double type all destructured parameters to functions. I'm partial to :> but I don't know enough about the TS compiler to know if that would cause issues. Thanks for looking into this.