Question about intellisense and operators+overload resolution

Back when I was polling on what people were interested in seeing in the next version of C#, I was interested to find out that most of the requests were related to the language itself and far fewer were about the tools.  I don't think that that means that people necessarily like the tools a lot, more that they're more intrested i seeing the language grow and improve and they would get a larger benefit out of that than the tools improving.

In the top 30 requests I say improvements to intellisense only account for about 6 items.  Intellisense corresponds to the set of tools that relate to giving feedback on your code as you're typing it (that's a terrible description, so hopefully Jay/Anson can do a better job).  Feedback in this sense is both helping you type what you know what you want to type and also helping you discover the system while you're actually coding (as opposed to by browsing a web page with documentation).  This includes things like completion lists, parameter help, colorization, navigation bars, smart tags, etc.  I've had many discussions with people who believe that intellisense is actually a detriment because it encourages people to dive into code without reading things like sepcs which can give them a greater understanding of the system as a whole.  I can definitely see the concern, but we also want to help those who are informed and just want to be able to get what's in their mind down in code faster and with a tighter feedback look between typing and knowing that there are problems.

With regards to that, I wanted to ask a question about people's satisfaction with respect to operator (and method)-resolution.  For example, take the following contrived case:

            int total;

            int players;


            string average = ((double)total / (double)players)<dot>


When you hit the dot we won't show any completion list there and you'll have to know what the expression will evaluate to and what operations are valid on that type.  Another case is something as simple as:

        int GetSomeValue(int i) { }

        string GetSomeValue(string s) { }


        void Example() {




Here we won't show a completion list because we don't do overload resolution and if we get a list of members with different return types we won't show a completion list. 

In VS2005 we added a form of “poor mans overload resolution” where we started taking into account the number parameters you'd typed to a method.  i.e. if you had:

        int GetSomeValue(int i, int j) { }

        string GetSomeValue(string s) { }


        void Example() {

            GetSomeValue(4, 5)<dot>



Then we would show a completion list because we would be able to completely exclude the second method when resolving the method.

So I was wondering how annoying this was for C# developers.  Do you run into this situation not at all, a little, a lot?  If so, are you bothered by it, again; not at all, a little, a lot?  I'm trying to get a sense for how this ranks on the list of things people would like to see.

In my opinion, it's definitely something that should be done (if you don't think so, let me know!), I just don't know how it would rank amongst all the other things people want us to do, and I wouldn't want to do this if there was something else that could be done that people thought was more important.  Also, I can imagine that for a VB developer used to having this functionality, coming to C# could be quite frustrating as it might cause you to think “am I doing something wrong?“  Well, actually, I can see any developer thinking that, but VB in particular because they've had this functionality for quite a while.

Note: this behavior is also evident with the “Generate Method Stub” feature we added in VS2005.  We will only show the smart tag to generate the stub if we are sure that you are calling a non existent method (and without overload resolution we can't be very sure of that fact).  So, instead we err on the side of not spamming you with a smart tag when there's a method that could match the one you're calling, but we always give you the option (through the menu, context menu, or keyboard shortcut) to manually invoke the feature.

Comments (10)
  1. Dr Pizza says:

    I dunno if I’d say I was annoyed by it, but I would say that I hadn’t realized why it didn’t show completion information in some situations. Now it seems clear.

  2. Stuart says:

    I do run into this quite a lot, and I’d love for it to work "right", but I can see that there are probably lots of other features that are more important.

    A related intellisense issue that gets on my nerves is when you have the little yellow tooltip indicating all the overloads of the method you’re calling, and can press ‘up’ and ‘down’ to scan through the overloads. VS is obviously quite capable of intuiting the type of an expression (it does when you press "."), so why doesn’t it use the types of the expressions you’ve already typed to narrow down the list of overloads to the ones that might apply?

    Failing that, at *least* preserve the overload that I’ve selected until I’m done typing it. Right now it pops me back to the first one if any one of the arguments is a method call that pops up its own tooltip…

  3. Stuart: The latter behavior has been improved in whidbey (not great, but better), when popping up to the outer method after finishing the call to the inner one we’ll at least select a method that has at least as many arguments as you’ve currently written.

    That way we don’t have you looking back at the one that takes no args when you’ve already written 6.

  4. Ron Green says:

    You mean like:

    SqlCommand cmd=new SqlCommand();

    cmd.Parameters.Add("@Name", SqlDbType.string)<dot>


    And then you have to type in Value="Homer";.

  5. Darren Oakey says:

    Cyrus – personally, I’ve rarely come across the problem… I guess it’s not the sort of code I’m likely to write. BUT

    if you’re looking for intellisense suggestions…. well… (deep breath)…

    1> the biggest request would be some sort of filtering of your lists based on types. In the perfect world, intellisense would only show us stuff which would compile.. for instance, if you had

    > class A { public int x;public string y;}


    > A value = new A();

    > string myValue = value<dot>

    The only thing we would see in the list would be "y"…. because you can’t legally assign an int to a string. to get the full list, you’d type

    > string myValue = (string) value<dot>

    or just

    > string myValue = (value<dot>

    This is especially apt when sending a value to a function.. if we have a function

    > void F( MyClass y ) {…

    and we say

    > F( <control space>

    We should only see functions/vars that return/have explicit casts into MyClass, which would DRASTICALLY reduce the intellisense list, and make it heaps more of a productivity tool.

    2> reserved words. I only ever type 3 letters of anything – I type 3 letters, and then hit control-space. The amount of times I’ve got confused when I typed pub<control-space> or cla<control space> and couldn’t find public/class/private or whatever is ridiculous!

    3> XML documentation "ALWAYS-ON" – it really bothers me that you have to jump through hoops to get your xml documentation to appear when you use a different assembly. Really, I would think it should be just impossible to turn OFF! if the original code is written with XML comments, then the documentation info is available when you are referencing that assembly – simple as that?

    4> VB style enum tips – passing parameters, assigning, setting, switch … anything that operates on an enum should present us with just a list of the valuse of that enum

    5> Integrated codereview – this is a lot more work, but it would be really nice to have all the features of FXCop available in the editor… for instance, type a dodgy variable name, it gets underlined. Go beyond 25 lines in a function, the background of the text editing changes to red. Implement ISerializable, the constructor appears in the code, without you asking for it… etc etc

    6> Spell checking – we actually use a third party product which does this, (Visual assist) but it would be nice to have it out of the box!

    7> Type matching for overloads – if you have three overloads for a function, f( string, int, int) f(myclass, int, int) f(int, int, int) – and you have typed f( blah, and blah happens to be a string type, then the intellisense has enuff info to pick one of the overloads… More interestingly, if you type f( myvalue, which isn’t implicitly convertable to string, myclass, or int, the intellisense should show up a red error saying no overloads are going to be found..

    By the way – I must say – intellisense is the _very best_ thing about Visual Studio. I think it’s been done very well, and offers massive productivity benefits.. I think you haven’t got many suggestions because we are generally very happy with it!

  6. Darren: Awesome info. First off, I’m surprised to hear you say that it’s been done very well considering all the places you showed where it was lacking. 🙂

    Ok, onto your points.

    1) In a perfect world we would have that. Unfortunately, there is a slight snag. Expressions can be arbitrarily complex and it’s extremely difficult to determine what is and isn’t valid. In your example I could haev wanted to write:

    value.X.ToString(), not just value.Y

    Considering that object exposes strings, ints and bools on it’s basic interface you end up realizing that the list of reachable types and valid expressions is pretty huge.

    Now, one thing we’ve considered is some sort of dual mode intellisense where you would have a list filtered down to likely suggestions based on heuristics, and a list that showed everything. Toggling with something like left/right would switch between the two modes.

    2) We’ve added keywords to completion lists

    3) XML docs _should_ always be on. Could you check out 2005 and tell us if you’re not finding that to be the case?

    4) We’ve adopted much of the VB style enum help. Automatically bringing up the list preselcted to that enum where appropriate.

    5) Agreed.

    6) Agreed. I spiked a feature like that a while back.

    7) I want to get overload resolution into VS and that’s why i was soliciting feedback on this. One issue that concerns me is performance. I only want to get it in if it won’t affect you at all.

    one of the areas that really affects that in C# is implicit conversions and the ability to jump all over the type hierarchy when resolving a method call.

    Thanks for your help!

  7. Personally, I would consider the current behaviour a bug. IntelliSense sets up a certain expectation and when that expectation is met in 95+% of the cases, the remaining 5% can only be explained one way.

  8. Michael: I’d actually argue that it’s met in very few places. Intellisense does no expression evaluation whatsoever. So the instant you go beyond a simple field of method access we do not have support. I would guess that it’s far below 95%. That said, it’s still very important that we address and fix this "bug". The problem is that this bug is not easy to fix and will require a lot of work.

    What I want to know is how important this is to users. Should we invest the time and fix up this behavior or should we invest in other areas?

Comments are closed.

Skip to main content