Ensure specialized signatures are always at the top when performing call candidate resolution#1562
Conversation
There was a problem hiding this comment.
This does seem weird, but this might be a problem with the strategy for signature help. Ideally, you would see the string overload because it is the most general.
There was a problem hiding this comment.
I personally feel like this updated behaviour is actually better, since it indicates to the author immediately that there are specialised signatures to pick from.
In any case, I am not sure that the extra complexity of doing something different would be worth the cost (it might be, if the only cost is to add a loop to skip hasStringLiteral signatures in this situation), but that is just my opinion.
There was a problem hiding this comment.
Yeah, in general the philosophy for signature help is to give the user a lens into the ordering of the signatures. In that respect I think seeing the specialized first is better. So I am good with the way you have it.
|
Thanks for the review! I will try to get these fixes to you over the weekend so you can do what you want to do next week. |
|
OK, the feedback should all be addressed now. Let me know if you need anything else from me on this, and thanks again for the review. |
|
Yup, looks good, thanks Colin! |
Ensure specialized signatures are always at the top when performing call candidate resolution
This patch ensures specialized signatures are always at the top when performing call candidate resolution. It also includes an update to the compiler/inheritedOverloadedSpecializedSignatures test to add the failing merge condition, and an update to fourslash/overloadOnConstCallSignature now that specialized signatures are ordered to the top of the candidate list.
Edit by @DanielRosenwasser: Fixes #1133