Overloaded method inference problem

This example, intended to demonstrate an immutable class with modifier methods that return a new instance:

class Foo(val bar: String, val baz: Int) {
    def bar(bar: String) = new Foo(bar, baz)
    def baz(baz: Int) = new Foo(bar, baz)
}

The first method seems acceptable to the compiler (and the other method too, if placed first), but the compiler seems to choke on the second one:
"overloaded method bar needs result type"

Notice it's complaining about the second method (line 3), yet the method name referred to is the "bar" on the right side of "=".

If I follow the "needs result type" part of the advice, the compiler is happy:

def baz(baz: Int): Foo = new Foo(bar, baz)

However, the error is partially misleading and that seems like a case the compiler ought to infer anyway, right?

I'm on the latest build of 2.8 throught the nightly Eclipse plugin.

On Sun, Mar 29, 2009 at 04:51:35PM -0500, Nils Kilden-Pedersen wrote:
> Is this a known problem or should I file a bug report?

I don't think it's a bug, you're just being too ambitious with your
overloading.

class Foo(val bar: String, val baz: Int) {
def bar(bar: String) = new Foo(bar, baz)
def baz(baz: Int) = new Foo(bar, baz)
}

The body of baz references bar (which is overloaded, as a val in the
constructor parameters and a def) and the body of bar references baz
(which is similarly overloaded) and on top of that you don't declare any
return types. That you ALSO gave the method parameters names which
shadow the overloads is just gravy, I don't think it hurts you any worse.

There's only so much you can expect it to infer with local type
inference when you go out of your way to make it a challenge.

On Sun, Mar 29, 2009 at 04:51:35PM -0500, Nils Kilden-Pedersen wrote:
> Is this a known problem or should I file a bug report?

I don't think it's a bug, you're just being too ambitious with your
overloading.

class Foo(val bar: String, val baz: Int) {
   def bar(bar: String) = new Foo(bar, baz)
   def baz(baz: Int) = new Foo(bar, baz)
}

The body of baz references bar (which is overloaded, as a val in the
constructor parameters and a def) and the body of bar references baz
(which is similarly overloaded) and on top of that you don't declare any
return types.  That you ALSO gave the method parameters names which
shadow the overloads is just gravy, I don't think it hurts you any worse.

There's only so much you can expect it to infer with local type
inference when you go out of your way to make it a challenge.

On Sun, Mar 29, 2009 at 07:30:09PM -0500, Nils Kilden-Pedersen wrote:
> I don't know. There's only one statement in each method: new Foo. How
> hard can it be to infer the return type of a one liner?

That kind of depends on the line, doesn't it?

> And remember, it's only on the second def. The first one is fine. Even
> if you switch. That seems like a bug to me.

I do remember. The reason it takes two is that it takes two to make a
cycle. The body of bar references baz; the body of baz references bar;
both are overloaded, and neither method declares its result type.

> Furthermore, the error is a little ambiguous. It complains about the
> return type, but references "*bar*". That is, if anything, confusing.

I have an open bug somewhere that CyclicReference exceptions basically
only report "recursive needs type" as an error despite the
fact that several situations give rise to them which are not well
summarized by that message. So the message might improve, but I predict
the answer to "how hard can it be" is "hard enough to leave it as it
is." The source is out there if you feel otherwise.