New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure of implicit conversion from {int, long, double} to {BigInt, BigDecimal} #4547
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4547?orig=1 |
@paulp said: As I read it, that translates to "this is a bug." I thought it might work with an expected type of BigInt, but it does not. Furthermore, the error message changes, implying that the expected type influences the set of applicable implicits, but not in a coherent way. scala> def g: BigInt = 5 + BigInt(4)
<console>:7: error: overloaded method value + with alternatives:
(x: Long)Long <and>
(x: Int)Int <and>
(x: Char)Int <and>
(x: Short)Int <and>
(x: Byte)Int
cannot be applied to (scala.math.BigInt)
def g: BigInt = 5 + BigInt(4)
^
scala> def g = 5 + BigInt(4)
<console>:7: error: overloaded method value + with alternatives:
(x: Double)Double <and>
(x: Float)Float <and>
(x: Long)Long <and>
(x: Int)Int <and>
(x: Char)Int <and>
(x: Short)Int <and>
(x: Byte)Int <and>
(x: String)String
cannot be applied to (scala.math.BigInt)
def g = 5 + BigInt(4)
^
|
@paulp said: |
@paulp said: |
@adriaanm said: |
Harrison Klaperman (hlklaperman) said: |
@adriaanm said: Available on my github (https://github.com/adriaanm/scala/tree/ticket/4547) now -- should land in trunk by 2.9.1 |
@paulp said: |
Commit Message Bot (anonymous) said: review by rompf -- odersky may want to take a quick look and update the spec |
=== What steps will reproduce the problem (please be specific and use wikiformatting)?
Compiler refuses to implicitly convert an Int to a BigDecimal, etc., in the following context:
=== What is the expected behavior? ===
Compiler should insert an implicit conversion, translating above to:
=== What do you see instead? ===
Errors like this:
I assume this is an error. If this is the behavior the spec requires in the presence of preexisting overloaded methods none of whose argument types match the type provided, I would argue that it presents a usability problem.
=== Additional information ===
I couldn't find any other tickets on this issue, but that might be because I was misformulating my search queries.
=== What versions of the following are you using? ===
The text was updated successfully, but these errors were encountered: