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, 7/20/2018 #25939

Closed
DanielRosenwasser opened this issue Jul 25, 2018 · 0 comments
Closed

Design Meeting Notes, 7/20/2018 #25939

DanielRosenwasser opened this issue Jul 25, 2018 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jul 25, 2018

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.
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

2 participants