Disallow overloading from breaking stable patterns

[dwijnand]

No description provided.

[SethTisue]

I had commented on the ticket:

It isn't obvious to me that we can just carve out an exception for this in the compiler unless we also change the spec?

But I noticed that it works fine in Scala 2, so that's precedent for considering this simply a regression and not a design change.

And Dale points out that the workaround suggested by original reporter, val x = Op.foo, compiles, so the compiler isn't bothered by the ambiguity when it's just a term, only in a pattern.

So all of that together convinces me that we don't need to question this as a design change, it's okay to just make it work.

[SethTisue]

Implementationwise, perhaps it would be more elegant to put the new smarts inside isStable? Of course, isStable is called elsewhere as well. Would anything else progress — or regress — if it were implemented that way?

[SethTisue]

Dale has tried putting it in isStable and all the tests still pass. Offhand, we can't think of any additional tests we could add that might show a difference.

So I'm going to hit "approve", but it isn't obvious to me which implementation is better. Perhaps someone else would like to weigh in on that? If nobody else has an opinion, Dale could make the call.