LJC Lambdas Hackday

[Brian Goetz]

> Okay, so there are two ways to fix this. One is to use more powerful,
> global type inference, but that has undesirable effects.

Right.  

> Okay, now go open up Iterable.java and count the number of into
> methods. :)  (Forgive me for being overly cute; couldn't resist.)

Duh.  We've of course considered this.  (Forgive me for being overly dismissive; couldn't resist :)  

But the problem is, it is a hack that doesn't really get you very far, and pretty soon we're having the exact same conversation -- because the underlying "gah, why doesn't the compiler know this, it is obvious" hasn't really been addressed, its just been moved around.  It is brittle (as soon as you add an overloading, it reduces to the same problem), irregular, and would likely cause problems down the road if we wanted to extend inference further in more sane ways.  If there was some reason to believe that overloadings in cases like this would never come up, we might be more inclined to think about it, but we have no reason to believe that the lack of overloadings here is not just an accident.  

The problem with hacking type inference is that it is an endless loop of:

 - Someone finds a case where type inference fails, but the right answer is "obvious"
 - Endless machinations and distortions ensue to try and make that case "go away"
 - Go to step 1

> Obviously you know better than I whether this can work, but it
> would make ::into a whole lot nicer without requiring much more
> smarts from type inferencing. In particular, it doesn't require any
> global inferencing, only knowledge about the receiver, which it
> must have to even begin overload resolution.

It would most definitely work.  But we would much rather find a better solution.