Overloading not working

[thany]

TypeScript Version: 3.5.1

Search Terms: overloading

Code

// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.

class JavascriptLoader {
	public static load(url: string): Promise<string> {
		// ...
	}

	public static load(urls: string[]): Promise<string[]> {
		// ...
	}
}

JavascriptLoader.load(['1', '2']);

Expected behavior:
Considering the fact that Typescript is supposed to support method overloading, it should be able to not only accept these functions in the class above, but also be able to select the best matching one when it is called on the last line.

Actual behavior:
The compiler spews out on each of the method declarations:

test.ts:6:16 - error TS2393: Duplicate function implementation.

On the call, it spews out:

test.ts:11:23 - error TS2345: Argument of type 'string[]' is not assignable to parameter of type 'string'.

Playground Link:
Playground link

Related Issues:
Just #31578 which looks a lot more complicated.

[cpplearner]

see #3442

[thany]

Looks like Typescript doesn't support overloading yet. Then I wonder why there are so many blogs that are bragging about the fact that it does.

Every simplified example is a function with a string argument, and another function with the same name with a number argument. They all claim it just magically works. So naturally I tried to replace string[] with number in my example, but even that doesn't work. All the same errors.

The issue you (@cpplearner) linked is a huge discussion on how to implement overloading, so, I'm confused now. Does or doesn't typescript support overloading??

[MartinJohns]

@thany TypeScript supports overloads, but differently than you may know it from other languages. As JavaScript does not support overloading, the overloading in TypeScript is essentially one function with multiple signatures.

Please check the official documentation for examples: https://www.typescriptlang.org/docs/handbook/functions.html#overloads

Also your issue looks more like a question: https://github.com/microsoft/TypeScript/blob/master/.github/ISSUE_TEMPLATE/Question.md

[dragomirtitian]

@thany Typescript allows you to overload the signature of a function. But since Javascript does not support overloading, it is up to you to actually discriminate which overload is called:

class JavascriptLoader {
    public static load(url: string): Promise<string> // signature 1
    public static load(urls: string[]): Promise<string[]> // signature 2 
    public static load(urls: string | string[]): Promise<string[]> | Promise<string>{ // implementation signature
        if(typeof urls === "string") {
            return Promise.resolve(urls) // signature 1 was called 
        } else { 
            return Promise.resolve(urls) // signature 2 was called 
        }
    }
}

[thany]

Exactly, so "overloading" is basically just an aid for intellisense. Real overloading it doesn't actually do.

As JavaScript does not support overloading, the overloading in TypeScript is essentially one function with multiple signatures.

It could generate multiple uniquely-named funtions, and translate the calls to them appropriately by choosing the most closely-matching one, as mentioned several times in #3442, but it doesn't yet seem to do that. Unresolvable ambiguity should result in an error.

So all I can conclude right now, is no real overloading.

[MartinJohns]

It could generate multiple uniquely-named funtions, and translate the calls to them appropriately by choosing

But this would be against the explicit TypeScript goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

Mostly the non-goal 1 and 5:

1 - Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript and the intentions of program authors as a guide for what makes the most sense in the language.
5 - Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

So all I can conclude right now, is no real overloading.

It is overloading as it's done in JavaScript, and TypeScript aims to be a super-set of JavaScript with additional type information. It doesn't aim to add new functionality to JavaScrript. It's just not overloading as you know it from other languages. If you want to call the one "real" and the other not... go ahead. But such a distinction won't help you or anyone else.

[thany]

It could generate multiple uniquely-named funtions, and translate the calls to them appropriately by choosing

But this would be against the explicit TypeScript goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

That's arguable at best. And even if so, perhaps the Design Goals are not what some developers want them to be.

So all I can conclude right now, is no real overloading.

It is overloading as it's done in JavaScript. Just not overloading as you know it from other languages. If you want to call the one "real" and the other not... go ahead. But such a distinction won't help you or anyone else.

Sorry, but function overloading means two or more functions with identical names, and different arguments and implementations. In every language. Typescript's interpretation of overloading is not overloading - it's called runtime type checking. It's literally nothing more than providing some richer intellisense hints. This is useful, but it doesn't help to build cleaner code.

Also it does help to not call it overloading, because of:

• What people expect by the term overloading.
• When real overloading is implemented after all anway, it might be confused with intellisense hinting that is currently implemented as "overloading".

[MartinJohns]

That's arguable at best. And even if so, perhaps the Design Goals are not what some developers want them to be.

Sure, you can argue as much as you want. But in the end it's a decision the team has made, for a good reasons. Every additional feature beyond the scope of JavaScript could mean incompatibilities in the future. That's not something most people want.

Typescript's interpretation of overloading is not overloading - it's called runtime type checking.

It's not even that. It's compile-time type checking. And that's literally the entire purpose behind TypeScript. It's just JavaScript with compile-time types. If you want more than that, then TypeScript is not the right language for you.

[thany]

Sure, you can argue as much as you want. But in the end it's a decision the team has made, for a good reasons. Every additional feature beyond the scope of JavaScript could mean incompatibilities in the future. That's not something most people want.

As long as there are good reasons. But people do make mistakes, and people to come back to their decisions from the past. I would not be surprized if this were to happen with any Microsoft product, including Typescript. Not meant offensively, just realistically.

It's not even that. It's compile-time type checking. And that's literally the entire purpose behind TypeScript. It's just JavaScript with compile-time types. If you want more than that, then TypeScript is not the right language for you.

Compile-type typechecking? Are you sure? In my book typeof urls === "string" is totally runtime. Pasting that code into the playground, we can see it not 'compiled away', hence runtime typechecking.

[MartinJohns]

That is your implementation, that is beyond TypeScript already. TypeScript makes sure you can call the function with the available overloaded signatures.

But I see no purpose in continuing this subject, so I will excuse myself and unsubscribe. :-)

[RyanCavanaugh]

We're extremely confident that not doing type-directed emit is the right thing to do. Compile-time overloading has been suggested to death and we don't need to turn the crank another time.