Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
We need to find an
Ordering[T]
for uninstantiatedT
. Before implicit arguments were takeninto 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.
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 this issue is that now implicit parameters are only considered if the result
types of two alternatives are unifiable. Hopefully, that's not too constraining.