Open Rodentman87 opened 1 year ago
This is definitely a duplicate of some issue - but I can't find a good umbrella issue for this right now. In this comment here I noted that:
Fixing this might require some effort/a different approach to how completions are provided in cases like this. Note that, for example, getStringLiteralCompletionsFromSignature is already using a different - overload-capable~ - strategy to provide completion directly at argument positions. This one is nested in the argument and thus a simpler approach of getContextualType is used here.
In general, completions at positions nested in arguments usually don't take overloads into account today.
Bug Report
🔎 Search Terms
Generic, Overload, Type Inference
🕗 Version & Regression Information
This is the behavior in every version I tried on the playground
⏯ Playground Link
Playground link with relevant code
(To see the issue in action, go to line 55 and add a comma to the parameters to trigger the completion and look at both overload options)
💻 Code
🙁 Actual behavior
In the IntelliSense/Autocomplete for
thing.setMetric()
(when specifying "test" as the first argument), the type of the first overload gets simplified to:and the type of the second overload doesn't get simplified at all
This behavior is not based on the second overload being more complex, if you swap the positions of the two overloads, the first one will get simplified to:
while the second one doesn't get simplified
🙂 Expected behavior
Both overloads should get simplified to:
and
regardless of their order in the overloads
Workaround
While it is possible in this case to just use a single definition for the method instead of the overloads:
having the two overloads makes it clearer that the method has two separate behaviors based on whether you're passing a raw value or a function to update to the value.