1

Closed

Remove overload ordering requirement

description

Back when TypeScript was v0.9.1 there was no need to order overloads in typing files. Then come 0.9.5 there was this breaking change:

Overload resolution rules simplified

Description: Overload resolution now follows a much simpler algorithm. When multiple overloads fit for a given call, we pick the first fit rather than the trying to find the "best fit".

This means that code with overloads should now be manually sorted from the tightest/more-specific overload to loosest. The one exception is that an 'any' in the callee will try to match an 'any' in the caller.
I understand the reasons for this but speaking as someone involved with the Definitely Typed project I would love to see a return to the previous functionality where ordering was no longer so key. It's easy to get wrong and frustrating to tweak it until everything lines up as you would hope.

Is this something you might consider in a post v1.0 world? Could we have the "best fit" functionality back?
Closed Apr 16, 2014 at 5:55 PM by RyanCavanaugh
We tried a bunch of different overload ordering algorithms during the design process and all of them ended up being really hard to understand, and still fell back on "first wins" or "last wins" as a last resort. People trying to write .d.ts files felt that the overload picking algorithm was giving unexpected results that were hard to predict.

Ultimately we decided that an overload picking algorithm that was trivial to explain ("first that works wins") was the best design. It gave API designers the most flexibility. It it doesn't require intimate knowledge of the type system to understand.

Now that 1.0 has shipped changing the overload picking would be a breaking change; given how many problems the first time we changed this was, and how many times we tried to have a 'smart' ordering algorithm, I don't see us changing this at all.

comments

johnny_reilly wrote Apr 16, 2014 at 6:42 PM

Well that's a shame. But thanks for the explanation. I must admit to being surprised that the algorithm was so problematic to implement given other languages (C# etc) have no need for specific ordering. Is there an obvious reason for the difficulty I've missed?