Add type declaration overloading

[SamPruden]

I'm keeping this relatively brief and loose for now as I haven't thought it through in excruciating detail yet, I may add detail later to flesh this out into more of a formal proposal.

There's a desire to have some form of type switching in the type system. I think #12424 is the main proposal that tackles this. This suggestion is yet another potential approach to that issue, as well as potentially adding some other little niceties to the type system.

If type declarations could be overloaded in much the same manner as functions, this would allow for type switching in a manner that's already familiar within the language. The rules would effectively be the same as that of functions.

• All overloads must be directly adjacent so that they have order
• The first matching signature is used to resolve the type
• Overload signatures may have different lengths
• If no signatures match, it's an error just as it is currently

type Foo<T extends number> = {aNumber: number};
type Foo<T extends boolean> = {aBoolean: boolean};
type Foo<T extends any> = {aDefault: T};

type FooNumber = Foo<number>; // = {aNumber: number};
type FooString = Foo<string>; // = {aDefault: string};

This idea was spawned in #17325, credit to @SimonMeskens for wanting to discuss it properly and pushing me to post it.

[SamPruden]

Potential problems: Does this clash with declaration merging somewhere?

[aluanhaddad]

@TheOtherSamP

Potential problems: Does this clash with declaration merging somewhere?

I think so. Even if we assume modules, Module Augmentations would make ordering perplexing.

If you have

// vendor/api.d.ts

export type Foo<T extends number> = {aNumber: number};
export type Foo<T extends boolean> = {aNumber: boolean};

export type FooNumber = Foo<number>; // = {aNumber: number};
export type FooString = Foo<string>; // = {aDefault: string};

and then add

// src/augmentations.d.ts

export {}

declare module 'vendor/api' {
  type Foo<T extends any> = {aDefault: T};
}

then ordering could be violated causing any to take precedence and subsume the other constituents of the overloaded type.

I might be wrong on this...

[SamPruden]

@aluanhaddad Hmm, why isn't this already a problem for function overloading? Actually, it seems like it is? I just threw a quick test together of the same thing with functions and it seems like it does add the overload, but it's not clear how the overload resolution is working.

Is there some reason this should be more of a problem than it already is with functions?

[aluanhaddad]

@TheOtherSamP I am actually suggesting that overloaded functions suffer from the same issues. This proposal does seem very useful though.

[SamPruden]

@aluanhaddad Oh right, okay. Yeah, it's interesting that that problem is pretty much baked into the language now then, I don't see that there's much that could be done to fix that without massive breaking changes. If that problem exists for functions already though, that means it would also exist doing this kind of type switching via #6606.

[KiaraGrouwstra]

@TheOtherSamP asked me to give my view on how this compares to #6606, another proposal that would enable overloading, be it through type-level application of overloaded functions.

Going by my list in #6606 (comment):

overloading covers:

• operate on boolean literals
• unwrapping like promised
• constraints, incl. (non-) union
• type subtraction
• type checking
• checking index presence

not covered is function application:

• angular factories
• higher-order functions (compose, curry, bind, reduce, filter, tuple map, ...)
• lenses

Going by my list in #16392:

• type manipulation: ReturnType, BoolToString, Matches / TypesEq / InstanceOf, ObjectHasElem, TupleHasElem, conditional errors, pattern matching, constraints, ObjectHasStringIndex, ObjectHasNumberIndex.
• function stuff: map over tuples / heterogeneous objects, reduce, filtering objects by predicate

tl;dr:

• when we do actually need to do stuff with functions (because we get them in through params) we would, for better inference, need a way to deal with those. seemingly no way around 6606 for this one.
• the other use-cases can pretty much be covered by an alternate methods of doing overloads like this as well, with a few (fixable) holes compared to 6606:
  • capturing inferred types (Optional Generic Type Inference #14400), useful for e.g. type subtraction (Subtraction types #4183, null / undefined case Non-null assertion operator and the typeof operator #17370), extracting return types (naively) / params from unapplied functions.
  • type currying, i.e. can't dynamically make isT<T, V> into a isBool<V>, can't think of use-cases that need this atm, but fixable with anonymous types (not aware of proposals).

[SamPruden]

Thanks @tycho01, that list is really great to have and makes a far better case for this than I could have on my own.

[KiaraGrouwstra]

If that problem exists for functions already though, that means it would also exist doing this kind of type switching via #6606.

The existing declare function foo(v: string): bar; declare function foo(v: number): baz; style overloads would get their return types for given inputs calculated with #6606, yeah.

For the type-level use-cases utilizing it for overload-based type checks / pattern matching though, an type-level approach like interface foo { (v: string): bar; (v: number): baz; } would seem more idiomatic though, to prevent excessive switching between expression/type levels.

In that sense, I think the clashing issue is not so much aggravated by 6606, as it doesn't so much encourage repeating names.
But yeah, can't blame this proposal either if it was already an issue beforehand.

[SamPruden]

For the type-level use-cases utilizing it for overload-based type checks / pattern matching though, an type-level approach like interface foo { (v: string): bar; (v: number): baz; } would seem more idiomatic though, to prevent excessive switching between expression/type levels.

Good point.

I suppose the argument could be made that we shouldn't add another place where the clashing issue manifests. I don't want to make that argument because I like this idea, but it does feel a bit wrong to put this in knowing that it's broken.

[KiaraGrouwstra]

Erroring on clashes is an effective way to deal with accidental clashes, yeah. Not sure about nice workarounds there.
Then again, that risky scenario is already seems to be where we are for functions now, I guess?

So this proposal: if a generic input fails to match, find overloads. I presume this to mirror how function overloads work now, picking the first that matches by input requirement, rather than also continuing if say return type calculations explode.

If the foreign overload is broader than yours or goes first, it might catch (some of) your cases. If it catches all, that could warrant a "warning, given these equal requirements things could never drop through to the second declaration". Some would be harder to disambiguate.

[SamPruden]

Very tired left-field thought: Could some operator (perhaps typeof) be applied to function types to generate matching (anonymous) type declarations? So rather than full #6606, typeof (<T>(o: T) => {item: T}) would become type <T> = {item: T}. I haven't really thought this through at all yet, just throwing it out really.

I'm thinking that it might be a way to avoid introducing the new syntax/concepts that #6606 is waiting on, and that overloaded type declarations should be capable of describing everything that function signatures can.

[SamPruden]

Although rest parameters might be a problem. I have a horrible feeling that may also need rest parameters in type declarations, and I'm not 100% sure what that would mean right now. It's also suddenly becoming a fairly hefty set of changes when you include that, but maybe that's acceptable when compared to the size of #6606 as it stands.

EDIT: Actually I think that wouldn't be an issue. I think you should only need a single type parameter for the rest parameter.

[aluanhaddad]

@TheOtherSamP

Although rest parameters might be a problem. I have a horrible feeling that may also need rest parameters in type declarations, and I'm not 100% sure what that would mean right now.

That sounds a lot like the Variadic Kinds proposal #5453

[SamPruden]

@aluanhaddad I think I was wrong there actually, that shouldn't be required. A single type parameter should be able to handle the rest parameter. I am, however, falling asleep and probably embarrassing myself by talking nonsense at this point, so who knows.