Skip to content

Why do we need to manually type unified overload signatures? #25352

Open
Open
Why do we need to manually type unified overload signatures?#25352
Labels
Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureSuggestionAn idea for TypeScript

Description

@bcherny
Boris Cherny (bcherny)
opened on Jul 1, 2018

Please close if this has been asked before - nothing came up when searching.

Search Terms

overload, function, multiple, default, combine, unify, top

Suggestion

Today, when defining an overloaded call signature you have to manually type the implementation. Would it be possible to extend contextual types so TS can infer the implementation's types from context, just like TS already does for non-overloaded signatures?

Use Cases

Today, contextual typing isn't able to infer parameter types for overloaded call signatures. Instead, users have to manually type the implementation.

Examples

Before

type Reserve = {
  (from: Date, to: Date, destination: string): Reservation
  (from: Date, destination: string): Reservation
}

let reserve: Reserve = (
  from: Date,
  toOrDestination: Date | string,
  destination?: string
) => { /* ... */ }

After

type Reserve = {
  (from: Date, to: Date, destination: string): Reservation
  (from: Date, destination: string): Reservation
}

let reserve: Reserve = (
  from,             // inferred as Date | Date = Date
  toOrDestination,  // inferred as Date | string
  destination       // inferred as string | undefined
) => { /* ... */ }

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. new expression-level syntax)

Activity

  1. Boris Cherny (bcherny)
    changed the title [-]SWhy do we need to manually type unified overload signatures?[/-] [+]Why do we need to manually type unified overload signatures?[/+] on Jul 1, 2018

  2. DanielRosenwasser commented on Jul 2, 2018

    @DanielRosenwasser
    Daniel Rosenwasser (DanielRosenwasser)
    on Jul 2, 2018
    Member

    This wouldn't be a breaking change in existing TypeScript / JavaScript code

    Actually, it would be, with the caveat that it wouldn't break any code using noImplicitAny.

  3. weswigham commented on Jul 2, 2018

    @weswigham
    Wesley Wigham (weswigham)
    on Jul 2, 2018
    Member

    I had a PR that implemented this awhile ago and it langushied for a long time. Daniel Rosenwasser (@DanielRosenwasser) if we actually want to look at it, I can refresh it again. There are some issues, like generic unification and debate of what the correct contextual return type is (union or intersection).

  4. Mohamed Hegazy (mhegazy)
    added
    SuggestionAn idea for TypeScript
    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this feature
    on Jul 2, 2018

  5. kjin commented on Aug 29, 2018

    @kjin
    Kelvin Jin (kjin)
    on Aug 29, 2018

    I'd like to +1 this as a feature request -- I have a use case where http.get in Node 10.9 has an overloaded type signature, and I want to easily write a function with the same type signature. Currently I can't automatically infer its arguments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions