Function Overloading

[thany]

Suggestion

Function overloading. Yes, again.

Take issue #3442 - a long discussion on how to implement and why. There's clearly demand for this feature. On the last comment it says this is not comforming with the design goals and non-goals of typescript.

Perhaps it would be time to adjust the design goals then? If there's demand for a feature, and you're refusing to make it because of a set of (arbitrary) bullet points, maybe it's time to rethink the decisions made in the past. They may no longer match with how typescript is used, or how we like to be using it.

Issue #32102 - a shorter dicussion about the confusing current implementation of what I now call "faux overloading". Confusion is seldom a good thing to introduce. But again in the last comment it says this feature has been suggested to death. Maybe take that as a sign that some kind of change is needed.

Before moderators lock this

Please refrain from locking this issue too, just because you don't agree. If you like to mute/unsubscribe from this issue, go right ahead. But some folks would most likely like to choose to continue the discussion.

Alternatively, unlock #3442.

[MartinJohns]

Re-creating issues about explicitly rejected suggestions won't help you or anyone else. It will only make the work harder for the TypeScript team and annoy users.

[RyanCavanaugh]

I'm not sure how to make it more clear that we've conclusively decided to not implement this feature. It conflicts with several of our design goals, and can't really be implemented at all given an erased type system.

I cannot spend the rest of my working days re-re-re-re-re-re-re-re-arguing features that we've determined dozens of times are a bad fit for the language.

[RyanCavanaugh]

If you like to mute/unsubscribe from this issue, go right ahead. But some folks would most likely like to choose to continue the discussion.

I will address this separately: This is our repo and we have an obligation to keep an eye on all active threads, both from a product management perspective and to watch out for abusive behavior. To that end, it is not an option for the people whose job it is to watch the repo to unwatch threads. But, again, we are not adding separate-body function overloading, we've made that clear many times, and there isn't a productive "discussion" to be had for people to sit around and complain about it. That is why we lock issues when there is no further productive discussion to be had - not doing so only serves to create more work for us.

As for adjusting design goals - we've had these goals, basically unchanged, for 7+ years, and the language is doing pretty OK so far. If you think those goals prevent you from using it in a way that is compatible with your desired aspects of a language, you need to find a different language.

[thany]

I get that you're all thumbsup'ing each other comments, and downvoting mine. And frankly I don't care at this point. That, my friends, is not helping yourself or anyone else. The ony thing this achieves is creating self-fulfilling prophecies that are the design goals. As long as you close&lock every issue that is in "violation" of these arbitrary rules, they will keep fullfilling themselves. And that, in this particular case, is if overloading can be considered a violation, which I think it isn't.

(And if you still think it is, then why does downLevelIteration exist?)

Anyway, with that out of the way.

You're saying it is completely impossible to have two separate functions which separate function bodies with the same name, but it is fine if their names are different? How can TS not know which one to pick? TS is typed, that's the whole point, so in can be 100% certain which function to compile a call to.

See this:

function go(x: number): void {
    // ...
}

function go(x: string): void {
    // ...
}

And then call it:

go(42);

It's 100% certain which of the two is meant.
Now, if you call it with an ambiguous type:

const foo: any = 42;
go(foo);

It should produce an error, because there's no overload of go that matches the supplied parameters.

Nowadays this is an exceedingly simple arithmatic implemented by basically every programming language, including those developed by your other Microsoft colleagues.

The only problem-but-not-really is when it's called from javascript. Javascript's types are in the worst case implicitly any, so this example function would not have an overload that matches that, so that will gracefully fail during compile-time.

[RyanCavanaugh]

I'm honestly baffled that you think we haven't thought about it to the degree demonstrated above. See comments in #9 about how the type-directed emit here has cases more complex than two trivially-distinguished primitives.