Question

Duplicate: Function overloading by return type?

---

Maybe this is a very silly question but I don’t understand why I can’t declare two methods that have the same signature when they have different return types.

public class MyClass {     private double d = 0;      public double MyMethod()     {         return d;     }      public string MyMethod()     {         return d.ToString();     } } 

I get a compile error that states that the class already defines a member with the same parameter types.

(Obviously the way I’m using this in my code isn’t as simple as my example code…but I think it gets the idea across.)

Am I missing something concerning OO design that makes what I’m trying to do an OOP anti-pattern? Surely the compiler should be able to determine which method I’m trying to use as long as I specifically tell it which one I want.

Given MyClass myClass = new MyClass(); I would expect the following code to work:

double d = myClass.MyMethod(); string s = myClass.MyMethod(); 

I would expect the following code to have problems:

var v = myClass.MyMethod(); 

But even in the case of var it should result in a compile error.

Can anyone see what I’m doing wrong here? I’m more than happy to be corrected. 🙂

Answer 1

It’s because of type coercion.

Say you have the following functions:

int x(double); float x(double);  double y = x(1.0); 

Now, which of the two prototypes should you call, especially if they do two totally different things?

Basically, a decision was made early on in the language design to only use the function name and arguments to decide which actual function gets called, and we’re stuck with that until a new standard arrives.

Now, you’ve tagged your question C# but I see nothing wrong with designing a language that can do what you suggest. One possibility would be to flag as an error any ambiguous commands like above and force the user to specify which should be called, such as with casting:

int x(double); float x(double); double y = (float)(x(1.0));    // overload casting double y = float:x(1.0);       // or use new syntax (looks nicer, IMNSHO) 

This could allow the compiler to choose the right version. This would even work for some issues that other answers have raised. You could turn the ambiguous:

System.out.Println(myClass.MyMethod()); 

into the specific:

System.out.Println(string:myClass.MyMethod()); 

This may be possible to get added to C# if it’s not too far into a standards process (and Microsoft will listen) but I don’t think much of your chances getting it added to C or C++ without an awfully large amount of effort. Maybe doing it as an extension to gcc would be easier.