Loose mode/über mode

#22665 and #23906

• Problem: we haven't seen as much engagement on this proposal as we've wanted.
• We don't want to drive this without user input.
  • Perhaps let more people use checkJs, and drive this scenario further.
  • Also should just speak to more users.

Named type arguments

#23696

• Having some concerns.
• Adding nameable type arguments means that that you've made type arguments
• Makes sense that you need some syntactic way to name a type argument.
  • Do we have any ideas for how that might work?
    • **kw_args?
• What is the compelling scenario?
  • Partial inference is the primary driver.
    • Want to name one type parameter, have the others be inferred.
  • Naming complex type arguments is a big problem.
• Declaration syntax that allows you to opt into named?
  • Could write them as destructuring-like syntax?
• Conclusion: we want something for partial type inference, and we want some explicit way to opt in to named type arguments.

Trailing commas in type argument lists

#21984

• Looks like an error
• Looks pretty gross
• What if we want to reserve the design space for omitted elements? (e.g. using it for partial inference)
• If we have more community interested, we'll reconsider it.

Inferring type predicates

#16069

• T extends Something ? Something<T> : Blah
• In filter, the predicate is contextually typed by a type guard.
• Want to be able to say "if we're contextually typed by a type guard, try to infer a type guard from the function body"
  • Need some sort of Truthy type predicate.
    • That way it works on a higher-order (i.e. type parameters).
• Could we express this in terms of conditional types?
  • Well it's not just T extends Foo ? true : false, since you don't know if T is used by multiple parameters.
  • That's why you use typeof paramName
    • So in a sense x is Foo is the same as (typeof x) extends Foo ? true : false
  • Maybe there's a way to unify these ideas.