Why can't two methods be declared with the same signature even though their return types are different? [duplicate]

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. :-)

Staffer

Thanks Greg! I had no idea this was a duplicate question. I did search before asking...but I guess I wasn't using the right terminology. – Staffer

No worries, the question I linked to has some really good answers. (Mine is only mediocre. :) – Keystroke

Yeah, I read through them and they definitely answered my question. I don't mind if this question gets closed...but it would be nice if it didn't get deleted so that if the next person to have this question doesn't know its caused "function overloading by return type" they can still find an answer. – Staffer

that's "called" not "caused"....I wish I could edit my comments in cases like this... – Staffer

What I tend to do, @mezoid, is cut'n'paste the old comment into a new comment and fix it before submit. Then as long as no-one's commented on the original comment in that 30 seconds (ie, the new one would be out of sequence), I just delete the old one, otherwise I delete the new one. – Quirinal

That's the only time the 30-second delay on comments is a pain :-) – Quirinal

Unfortunately, deleting comments is only possible for people with rep > 5k....so until I reach that level I'll have to be careful of why I write in comments...or hope I can delete my comment before anyone responds :-) ...which in this case isn't possible LOL – Staffer

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.

Quirinal

As you say, this is a language design issue. According to Don Box, the CLI does actually permit return-type overloads (although no languages do). amazon.com/Essential-NET-Common-Language-Runtime/dp/0201734117/… – Silkweed

Answer 2

There's nothing from stopping you from calling your method without "capturing" the return type. There's nothing from stopping you from doing this:

myClass.MyMethod();

How will the compiler know which one to call in that case?

Edit: Adding to that, in C# 3.0, when you can use var, how will the compiler know which method you're calling when you do this:

var result = myClass.MyMethod();

Balmy

Answer 3

Because the return type isn't all that important when calling a method. It would lead to ambiguity in many cases to have methods only differing by return type. You might not store the result in a variable at all, or do something like this:

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

The compiler would have no way to figure out, which of the methods you wanted to call.

Kilgore

Answer 4

A method signature is the name and input parameters (type & order) only. The return type is not part of the signature. Thus two methods with the same name and input parameters are identical and conflict with each other.

Jiujitsu

Answer 5

What, if any, variable you're assigning the method to can't inform the compiler which method to use. Imagine:

String message = "Result = " + myClass.MyMethod();

Rabat