What's not correct? I said Java needs to decide the return type, not Rust, or some other language.

> Java needs X, meaning you can't Y

X and Y are certainly both possible, even if the Java languages chooses not to have Y.

Parse error: implicitly the author intended "Java needs X, meaning you can't Y in Java".

Please read charitably and give the poster the benefit of the doubt.

> Parse error: implicitly the author intended "Java needs X, meaning you can't Y in Java".

Except the second clause does not generally follow from the first yet is presented thus. You can't Y in Java because Java very specifically decided not to support Y.

The correct statement is

1. Java needs X.

2. Unreleatedly, Java chose not to Y.

You're stating "you can't differentiate between method implementations based on return type alone" which is nonsensical both on its face (people have no issue doing it) and technically (since several languages do exactly that).

And thus "Java needs to be able to decide which overloaded method implementation to use at compile time" is not an issue relevant to return-type overloading.

There was no issue with Java implementing return-type overloading, the creators of Java decided not to do it for non-technical reasons.

Oh, I see. My language may have been imperfect, but I think the meaning is clear. Obviously it's possible to differentiate based on return type, by very definition of it having a different return type, and also that the mentioned bytecode does just that. I see no reason why you would assume that the second half of the sentence was supposed to apply to languages generally when the first half mentions Java specifically. "Java needs to decide if you want a method to be public at compile time, so you can't leave out the public keyword and expect it to be public". Not true, says you, they could have made public methods the default.

Anyway, I think we understand each other now, and I shall endeavor to be clearer in the future.

It could be allowed. Consider the case of var-args method called with a null value. Say you call the method ambiguousNull(String ...args) like so:

    ambiguousNull(null);

Should args be null? Or should args be new String[]{null}? In the absence of any more information the compiler chooses the first, but may still issue a warning. But you can clearly disambiguate by casting:

    ambiguousNull((String)null); // args is null
    ambiguousNull((String[])null); // args is a 1-element array

So given

  int something() { }
  String something() { }

A hypothetical calling syntax could be

  (int)something();

Or the compiler could even choose one for you with a warning. Seems like a good suggestion for Java 10.

It seems like a in the case of var args, the args should always be an array, since the meat of most var args based functions is iterating over that array.

Even if you have a language that forces you to assign the return value, what does the compiler do in a situation like:

  Integer getSomething()
  String getSomething()

when the calling site is:

  Object something = obj.getSomething();

The compiler would tell you that it can't disambiguate that and fail. It's a type error.

I guess that makes sense. It is similar to:

  void putSomething(Integer i)
  void putSomething(String i)

and

  obj.putSomething(null)

which I think throws a compiler error in java.

The Haskell solution is to require a type annotation if the type is ambiguous.

Of course, Java provides no way to do that.

Well, I presume `String something = getSomething(); Object s = (Object)something;` would be okay.

Note that in Rust we don't have inheritance (not exactly the same kind, at least), so it's rare where a statically typed value can be referred to with a different type. So there are still annoyances in Java with this approach that Rust wouldn't have.

This and other questions are discussed at http://stackoverflow.com/a/442291