Java - why no return type based method overloading?

Question

I know this is not possible but can anyone provide a theory as to why Java chose not to support this? I am asking because I just ran into a situation where I think it would be nice to have.

Answer 1

It's because you are free to ignore return value.

Answer 2

Because you are not required to capture the return type of a method in Java, in which case the compiler can not decide which overload to use. E.g.

boolean doSomething() { ... }

int doSomething() { ... }

doSomething(); // which one to call???

Answer 3

I think you may find solution in below link.

http://stackoverflow.com/questions/442026/function-overloading-by-return-type

Answer 4

While it is theoretically possible, it was not used in Java for the same reason it wasn't used in C++; namely, it has been found that overloads based on return-types are generally more confusing to developers, the benefit is marginal compared with the costs of implementing it, and it would be ambiguous in the case where the return-type is not assigned to a value. For those reasons return-type based overloading is not supported.

Answer 5

I think one of the reasons is that, in most case you can determine the return type of a function only after the execution of the function instead of before this process. Thus, it can not help you decide which overloaded function to invoke just based on different return types of functions.

Answer 6

I've wondered why they don't support this also. Sure, if you ignore the return value, the compiler would have no way to know which you wanted. But that's the same ambiguity that arises with passing nulls. Like:

String doSomething(String s) { ... }
String doSomething(Integer s) { ... }
...
String out=doSomething(null);

In this case, the compiler just complains that the call is ambiguous, and you have to resolve it by casting the null, like:

String out=doSomething((String)null);

You could do the same thing with overloading by return type:

String getSomething() { ... }
Integer getSomething() { ... }
...
Integer n=getSomething();

would presumably call the second function.

getSomething();

would be ambiguous (and in this example, probably useless, unless it had side effects, but that's another story), so you'd have to say:

(String) getSomething();

More realistically, perhaps:

if ((String) getSomething()==null) ...

But that's the easy case. I can see a compiler-writer not wanting to support this because it could get very complicated to figure out in anything other than a simple assignment. For example, consider:

String getSomething() { ... };
Integer getSomething() { ... };
String getOtherthing() { ... };
...
if (getSomething().equals(getOtherthing())) ...

The compiler would have to figure out that both String and Integer have equals functions, so either one is valid at that point. Then it would have to notice that getOtherthing is a String, and Integer.equals(String) is unlikely, so probably what the writer wanted was String.equals(String). Do-able, but at that point I'm starting to see that in the general case, this could be a beast.

And then suppose we add:

Integer getOtherthing() { ... };

Now what does the compiler do with that IF statement? It could use the String versions of both functions, or the Integer, but not the String of one and the Integer of the other. At that point it would have to insist on a cast to tell it which, I guess. But the complexity is really getting out of hand.

And if it's hard for the compiler to figure out what you really mean, imagine what it would be like for another programmer who can't look up all the function signatures as fast as the compiler can.

Answer 7

Because Java can cast the return type value to the target variable, so it doesn't know into what variable type are you storing the return value of the function.