Imported From: https://issues.scala-lang.org/browse/SI-7062?orig=1
Reporter: @paulp
Affected Versions: 2.10.1-RC1
See #6667

@retronym said:
Before the fix to #6667, the presence or an expected type would put the typer into silent mode which would convince the implicit search to fallback to the implicit companions. (package object foo contributes to the implicit scope of class SeqInt).

@retronym said:
Wait, I need to look at that again...

@retronym said:
Yep, that's it.

@paulp said:
Not sure why you closed this. Maybe you didn't understand; we can't break working code in 2.10.1.

@harrah said:
The most unfortunate part is that seqInt from the package object is picked instead of the parameter ev, which is probably the least expected result compared with ambiguity (which is spec'd, I think) or picking ev.

@paulp said:
Heh, I didn't notice that. Yes, that's pretty bad. But it's still the case that people don't want 30 new compilation errors which they have to figure out (and have to make changes which may introduce other bugs) in a point release.

@retronym said:
I'm happy to revert the change for 2.10.x. I could also continue to issue the new error under -Xfuture. WDYT?

@harrah said:
In general, I agree with not introducing new compilation errors in point releases and all of the compatibility concerns. Perhaps the source compatibility situation is such that we never ever intend to change compiling code into non-compiling code. However, I don't think the current behavior is the desired behavior 99% of the time and user-code that compiles because of this hides a bug. If it were the other way, with the ev parameter selected, I'd agree that it should be left as is without question. Since it is not, I think it should at least be considered to be a new warning (I'm don't like warnings and I don't like introducing warnings in a point release) if not an error.

I'm also guessing this behavior will change for 2.11, in which case I think it is even more important to keep too much code from relying on this. Worst case, put it under -Xfuture. I doubt many people will use the option, but at least I'll know about it! This would mean -Xfuture needs to be reliable/supported and the behaviors it enables documented. Maybe there just aren't any yet, but -Xfuture Turn on future language features. doesn't seem to suggest it is expected to be used for production.

@paulp said:
We discussed it this morning and agreed we should warn under -Xlint. I am reluctant to push any harder than that. (I also agree we should put it under -Xfuture.) We can also use that as a reason to advertise -Xlint better.

@retronym said:
I leaning to towards an unconditional warning. It can be addressed in a backwards compatible manner by passing the parameter explicitly or avoiding the otherwise avoiding initial ambiguity.

This thing usually comes up from implicits in package objects, which should probably require a SIP-18 pass, as they cause all sorts of problems.

@retronym said:
Our comments crossed, I'll put it under Xlint.

@retronym said:
scala/scala#2063