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() {

            GetSomeValue(4)<dot>

        }

 

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.