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() {
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.
Comments
- Anonymous
July 18, 2004
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. - Anonymous
July 18, 2004
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... - Anonymous
July 18, 2004
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. - Anonymous
July 19, 2004
You mean like:
SqlCommand cmd=new SqlCommand();
cmd.Parameters.Add("@Name", SqlDbType.string)<dot>
?
And then you have to type in Value="Homer";. - Anonymous
July 20, 2004
The comment has been removed - Anonymous
July 20, 2004
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! - Anonymous
July 26, 2004
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. - Anonymous
July 26, 2004
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? - Anonymous
June 18, 2009
PingBack from http://barstoolsite.info/story.php?id=3814