Fix numeric implicit args #902
Conversation
Compiling scala.math.BigDecimal and scala.math.BigInteger shows a problem.
The conversion `int2bigInt` is not applicable to a Byte because `Byte -> Int`
requires another implicit conversion.
We fix that by using a new method relaxed_<:< for implicit compatibility checks,
which always admits numeric widenings.
This leads to another problem. Now the conversions
implicit def byteToInt(x: Byte): Int
implicit def byteToShort(x: Byte): Short
are ambiguous when we try to convert from Byte to Int.
We fix that by adding a "tie-break" to implicit search
where if several methods match a numeric value result type
and all have numeric value types as result types, we
pick the numerically largest type that matches.
Dotty delivers an ambiguity error. The comment in the test argues why this is OK.
and explain why it's different now.
odersky
force-pushed
the
fix-numeric-implicit-args
branch
from
1e17cc2 to
3460856
Compare
|
So, this PR allows the following code to compile: class Foo
object Test {
implicit def fooToShort(x: Foo): Short = 1
val x: Int = new Foo
}This was not allowed in Scala so this is a language change, should we write an SIP for it? It seems like a useful feature to me, but it complicates the rules for implicit resolution and the implementation (if I'm not mistaken, the |
|
@smarter Interesting example. Scala 2 has the concept of "weak conformance" which handles some of the things this PR addresses. We made a decision not to go with weak conformance because it is complicated. But without this PR, the standard library does not compile (for the reasons given in the commits). It seems to me the Dotty proposal is more local and less sweeping than weak conformance. It only applies to implicit search. In essence, it means we allow some implicit conversions (namely those between numeric types) to be composed with other conversions in implicit search. So this is an exception to the rule that generally implicit search is not transitive. And we need to clean up the fallout of possible ambiguities by a tie-break which essentially says the less distance covered by those additional numeric conversions the better. I think that design is still a net win over weak conformance, but if people disagree or want to propose another alternative how to deal with this, I'd be interested to see some arguments. |
|
No additional arguments, so I am merging this for now. We should revisit the issue of weak conformance in the future. |
|
Would a small set of implicits like this one help? This one permits @smarter's example to compile on Scala 2. |
|
No because we run into the transitivity issue. On Mon, Nov 9, 2015 at 10:07 AM, Jon Pretty notifications@github.com
Martin Odersky |
Fix problems encountered when trying to compile math.BigInt and BigDecimal. Review by @smarter or @retronym