I've got some fun LINQ-related discussion to post soon, but I
thought it'd be good to add a bit of a wrap-up to the last discussion
here about overload resolution. I was happy at first having
verified that our behavior matched the spec, so I moved on to various
other things. However, the customer who brought the issue to me
in the first place was unsatisfied with this response. He wanted
to know the reasoning behind the behavior, not just that we had
documented our behavior correctly. Thanks to Jeffrey Sax for raising this issue, and hounding me about
it until I delved deeper and really thought about C# language design. Since
much of my job involves verifying the compiler's behavior against the spec, it's easy
to forget that I also need to be continually evaluating that spec and the decisions
we've made in the past.
His blog post on the subject is a great read and highlights both the design principles behind
the decision to prefer more derived methods and some of the problems with it, so
I won't go into too much detail, but if you read my previous article on overload
resolution, I highly recommend it.