Better information in error cases

Dr. Pizza raised an interesting point in response to the previous post about method overload resolution, specifically:

“...but I would say that I hadn't realized why it didn't show completion information in some situations. Now it seems clear”

I thought this was pretty important to call out because it it exemplifies a problem that can arise when you work on a product for too long.  Namely, you start to recognize and accept the limitations of your current implementation and you don't realize that from the end users perspective something will just seem broken and they won't have any idea why.  What's worse is that often times people end up confused, suprised or thinking that they've done something wrong.

With regards to the previous post, let's look at completion lists.  A simple description of a completion list would be that is shows possible things that you would want to type given the current code context.  Note: we can't say “show all valid things that could be written at this point” as you might be writing something like a method call to something that doesn't exist.  There are also issues given the nature of code to be continuously broken as you're in the middle of typing it, and for parse trees to often be in very confusing shapes, which can cause all sorts of fun disambiguating scenarios to arise.  And, for the most part if you're typing complete gibberish we will probably to a pretty bad job of dealing with the situation.  (Just try typing your language of choice in an editor designed for another language and see how long it takes for it to get unhappy).  However, if you are writing reasonable C# code then it is certainly reasonable to expect this feature to “work” given the above intuitive definition.  And, given the extreme cases that cause completion lists to screw up, you might reasonably be unsure why things weren't working when you were typing fairly normal code.

So the question I have is “is it necessary to try and convey that information to the user” and, if so, “how?”  C++ currently just says “Intellisense: 'Type of expression to the left of the . has a type which could not be resolved'” in the status bar.  Would similar messages be useful to users, or just spam?  Something akin to “type of expression could not be evaluated because it contains an operator in it” or “unable to resolve method call to a single overload of Foo”?  I don't like the latter because it seems to imply that you've done something wrong and that when you compile you'll get a message about an ambiguous call to a method.  However, when it compiles correctly you'll probably be asking yourself “what the heck was that message talking about!?”  Of course, it's not pleasurable to think about announcing to the user: “sorry, couldn't do that because it just isn't supported”, but if it was valuable feedback and prevented users from thinking that their code was at fault, then it might be a reasonable thing to do.