5

Possible Duplicate:
Generic methods and method overloading

Say I have a class like

class SortedList<K>
{
    public string this[int i] { get { return "a"; /* dummy sample code */ } }
    public string this[K key] { get { return "b"; /* dummy sample code */ } }
}

Now let's say some dude decides to use it:

static string Test1<K>(K key) { return new SortedList<K>()[key]; }

The compiler resolves this call to the K key overload.

Now, contrast this with saying

static string Test2(int key) { return new SortedList<int>()[key]; }  // whoops

where the compiler resolves this to the int i overload.

Now if some poor soul says Test1(0), he'll get a different result then if he says Test2(0), even though the bodies look pretty much identical at first glance.

The funnier thing is, in neither case does the compiler or runtime detect an ambiguity and give an error.
Instead, the runtime just changes its behavior with respect to whether the value is generic or not, which can be clearly unexpected for the caller.

Why is the behavior inconsistent?
Or, better yet, why is there no compiler (or runtime) error because of the ambiguity?

Community
  • 1
  • 1
user541686
  • 205,094
  • 128
  • 528
  • 886
  • @SergRogovtsev: Wow, nice find! Didn't see that one; seems to answer this perfectly. We should vote to close my question then. – user541686 Aug 26 '12 at 06:27

2 Answers2

0

why the hack do you think, that this is inconsistent behaviour? it's just the point, that you OVERRIDE the index-getter with a "maybe-key"-type getter...

what do you think, should be the expected result? a warning? it's the developer's need to check what types you want to use for which generics... it's intelligent enough to check, that the method "test1" will address the key-based getter and test2 only the index-based getter...

you have to either disallow "int" as type (with class-constraint for example) or implement an other getter-method here...

TheHe
  • 2,933
  • 18
  • 22
0

Because the compiler doesn't call out warnings or errors about things that it suspects might appear ambiguous to you. It calls out things it finds to be ambiguous. But there is nothing ambiguous to the compiler here.

Let's say I hand you squares and rectangles and tell you to put the squares into pile a and the rectangles into pile b. Furthermore, you don't have to look at the objects to see if they are squares or rectangles because they are already labeled as such. Now... at some point I hand you an object that is marked as a rectangle but you notice that it also happens to be a square. Now, I didn't tell you to analyze the objects... I told you just to follow directions and organize them according to how I labeled them. And that's how the compiler works... doing exactly what you tell it to do.

Brandon Moore
  • 8,590
  • 15
  • 65
  • 120
  • Sure, but can't the runtime give an error? It would seem better than giving inconsistent behavior. – user541686 Aug 26 '12 at 06:23
  • Many people end up arguing (in so many words) that the fact that a compiler does something a certain way must mean that it's right. I typically disagree with that logic. However this case is different because you say that the behavior is inconsistent, but at the same time you pointed out that it *IS* consistent when you said it chooses based on whether the value is generic or not. So who's really being inconsistent here? :p – Brandon Moore Aug 26 '12 at 06:33
  • Huh? Generics give different behavior from non-generics, even though the type substitutions are the same. I call that inconsistent. – user541686 Aug 26 '12 at 06:43
  • See the paragraph I just added to my answer. – Brandon Moore Aug 26 '12 at 06:50