-2

I know, this is more of a rant than a question, so vote to close if you don't feel my pain. But this is just soooo annoying.

I think, it would relieve a lot of the stress I feel every time I get this error, if someone could reasonably explain to me why this requirement is actually needed.

I (kinda) get it in case of recursive methods, but what is so special about overloading?

Dima
  • 39,570
  • 6
  • 44
  • 70
  • 1
    Maybe it's to encourage people not to use overloading? :) – Travis Brown Jun 30 '16 at 21:20
  • @TravisBrown really? I never heard about overloading being frowned upon. What's wrong with it? – Dima Jun 30 '16 at 21:23
  • See e.g. [this answer](http://stackoverflow.com/a/2512001/334519). There are also some horrible overloading-related bugs like [this](https://issues.scala-lang.org/browse/SI-9074). – Travis Brown Jun 30 '16 at 22:26
  • @TravisBrown "Can make it _a little harder_ to lift a method into a function" Really, _that_'s the reason – Dima Jul 01 '16 at 02:39
  • 1
    @TravisBrown That was a package-object-related bug... – som-snytt Jul 01 '16 at 13:29
  • @som-snytt bugs can have many relations. – Travis Brown Jul 01 '16 at 13:43
  • @TravisBrown, that's true. But if you are going use the existence of a bug, "related" to a particular feature as an argument against using that feature, then, by that logic, the use of package objects and type parameters should be discourage as well, shouldn't it? – Dima Jul 01 '16 at 13:48

1 Answers1

0

Explicitly annotating the return type of an overloaded method is required only when it calls a method with the same name.

E.g. in this case you have to annotate the second foo

def foo(x: Int, y: Int) = x + y
def foo(x: Int): Int = foo(x, 42) // return type is mandatory

but in this case you don't

def foo(x: Int, y: Int) = x + y
def foo(x: Int) = x + 42

I'm just speculating here, but it looks very similar to the recursive call case, in the sense that it follows the same spirit. The type inferencer works locally and when it sees what it looks like a recursive call (in this case a call to a method with the same name), it stops and asks for an explicit type.

I think both cases (recursive calls and overloaded calls) derive from the local nature of the type inference algorithm, that won't escape the bounds of a method definition to infer its type.

Gabriele Petronella
  • 106,943
  • 21
  • 217
  • 235
  • That kinda makes sense.. except, if the compiler wasnt able to tell the difference between recursion and overloading it wouldn't be able to give different error messages, would it? – Dima Jul 01 '16 at 01:36
  • fair point. I guess it can tell the difference by looking at the signature, but it deliberately doesn't infer the return type. Again, speculating, but there may be corner cases due to nominal subtyping that make the inference impossible or at least very complicated. – Gabriele Petronella Jul 01 '16 at 08:11
  • Result type is taken into account in overload resolution (unlike in java). In the example, applicability based on args alone might select the other foo, but in general, the result type of the two foos might decide which foo is invoked. – som-snytt Jul 01 '16 at 13:36
  • Thanks @som-snytt that makes sense – Gabriele Petronella Jul 01 '16 at 13:38