You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have noted that the "more implicit parameters first" rule when applied
unconditionally can lead to implicit search explosion. The test case is
i3430.scala:
println(Nil.min) // error: ambiguous
We need to find an `Ordering[T]` for uninstantiated `T`. Before implicit arguments were taken
into account we'd try two types (in this case Long and BigInteger) and get an ambiguity. Then
we'd check whether any of the other candidates would dominate both of these types, which was
not the case. So, we are done with an ambiguity.
But when implicit arguments were taken into account there are many types that still are better
then these. E.g.
[T1: Ordering, T2: Ordering]: Ordering[(T1, T2)]
and so on far all other supported arities of Ordering for tuples! So one of these has to be tried.
That leads to searches for other uninstantiated orderings and so on. Running i3430.scala by hand,
I got a compiler hang. I am not sure why the test suite succeeded nevertheless; there must be
something surprising going on in the tests.
My fix to get round these issue is that now implicit parameters are only considered if the result
types of two alternatives are unifiable. Hopefully, that's not too constraining.
ambiguous implicit arguments: both object Long in object Ordering and object BigDecimal in object Ordering match type Ordering[B] of parameter cmp of method min in trait TraversableOnce
0 commit comments