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, 6/13/2018 #24940

Closed
DanielRosenwasser opened this issue Jun 14, 2018 · 2 comments
Closed

Design Meeting Notes, 6/13/2018 #24940

DanielRosenwasser opened this issue Jun 14, 2018 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Rest parameters and tuple types

#24897

  • In a nutshell, the type of a rest parameter can now be a tuple.

    • Previously we said rest parameters could only be arrays.
    • What this means is that an n-tuple-trailed rest parameter (i.e. (arg0: boolean, ...args: [number, string])) is the same as having n trailing parameters (i.e. (arg0: boolean, arg1: number, arg2: string)).
  • Because we need to encode everything that parameter lists have, we need a few things: empty length, optionality and open-endedness parameters

    • Now have an empty tuple types.
    • Also now allowing tuple elements to be optional using ?.
      • Means that the length becomes a union of
      • Is the ? part of the type?
        • No, it's a modifier for tuple elements
      • We said last week we'd be okay giving the syntax up for this case.
        • In that context.
        • And plus, we already recognize this in JSDoc anyway, so we've already effectively given it up.
    • Rest args mean we need open-ended tuples.
  • Currently can't operate on generic type argument lists.

  • All methods are generic on the called function (they use a this parameter to infer the parameter types of the functions themselves.)

    • Can Function itself just be made generic instead of doing this?
      • Well, doesn't work with overloads.
      • Well there are just going to be things that don't work.
  • What doesn't work?

    • Inferring from a generic argument list:

      function call<T extends unknown[], U>(f: (...args: T) => U, ...args: T) {
          f()
      }

Conditional type relationships

#24821

  • Today, a type isn't assignable to a conditional type unless it's another conditional type.
    • Makes it hard to actually implement something that returns a conditional type.
  • We also have what are called "substitution types": constraints that are built up in every conditional type's extends check.
    • If you're in the false branch, this PR builds up negated constraints.
  • To perform assignability checks, we first assume that
  • But a conditional type can give you a false positive for when the runtime type is more derived.
  • What about T extends T ? ... : ...
    • Should still work.
    • Will have to think about this.
  • Mixed assuredness

More conditional type relationships

#22735
#24929
#23541

Also, how far do you want to go?

function 
  • We want to take baby steps.
    • One good baby step - if you're assignable to both branches, it should just work.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 14, 2018
@ajafff
Copy link
Contributor

ajafff commented Jun 14, 2018

How do open ended tuples work w.r.t. their length property. Is this an infinite union? Is this something range types (#15480) would be useful for?

@mhegazy mhegazy closed this as completed Jun 14, 2018
@mhegazy
Copy link
Contributor

mhegazy commented Jun 14, 2018

How do open ended tuples work w.r.t. their length property.

it is a number.

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

3 participants