Skip to content
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

Closed
scabug opened this issue May 5, 2011 · 9 comments
Closed
Assignees
Labels

Comments

@scabug
Copy link

scabug commented May 5, 2011

=== 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:

  3 + BigDecimal(4)
  3 + BigInt(4)

=== What is the expected behavior? ===
Compiler should insert an implicit conversion, translating above to:

  BigDecimal.int2bigDecimal(3) + BigDecimal(4)
  BigInt.int2bigInt(3) + BigInt(4)

=== What do you see instead? ===
Errors like this:

<console>:6: error: overloaded method value + with alternatives:
  (Double)Double <and>
  (Float)Float <and>
  (Long)Long <and>
  (Int)Int <and>
  (Char)Int <and>
  (Short)Int <and>
  (Byte)Int <and>
  (java.lang.String)java.lang.String
 cannot be applied to (scala.math.BigInt)
       3 + BigInt(4)
       ^
<console>:6: error: overloaded method value + with alternatives:
  (Double)Double <and>
  (Float)Float <and>
  (Long)Long <and>
  (Int)Int <and>
  (Char)Int <and>
  (Short)Int <and>
  (Byte)Int <and>
  (java.lang.String)java.lang.String
 cannot be applied to (scala.math.BigDecimal)
       3 + BigDecimal(4)
       ^

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? ===

  • Scala: 2.8.1
  • Java: Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_20
  • Operating system: Mac OS X 10.6.6
@scabug
Copy link
Author

scabug commented May 5, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4547?orig=1
Reporter: Harrison Klaperman (hlklaperman)

@scabug
Copy link
Author

scabug commented May 5, 2011

@paulp said:
The spec says: "3. Inaselectione.m(args)witheoftypeT,iftheselectormdenotessomemem- ber(s) of T , but none of these members is applicable to the arguments args. In this case a view v is searched which is applicable to e and whose result con- tains a method m which is applicable to args. The search proceeds as in the case of implicit parameters, where the implicit scope is the one of T . If such a view is found, the selection e.m is converted to v(e).m(args)."

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)
                 ^

@scabug
Copy link
Author

scabug commented May 5, 2011

@paulp said:
Oh wait, as I read it again it is not "this is a bug", because the implicit is in the companion object of the argument. I was thinking it was in Predef. So it is not in the implicit scope.

@scabug
Copy link
Author

scabug commented May 5, 2011

@paulp said:
I agree that this presents a usability problem.

@scabug
Copy link
Author

scabug commented May 10, 2011

@adriaanm said:
fix pending

@scabug
Copy link
Author

scabug commented May 10, 2011

Harrison Klaperman (hlklaperman) said:
Thanks for the really quick turnaround on this. Is the planned solution to add conversions to Predef?

@scabug
Copy link
Author

scabug commented May 10, 2011

@adriaanm said:
No, this required a compiler change so that the spec is implemented in a more liberal way.

Available on my github (https://github.com/adriaanm/scala/tree/ticket/4547) now -- should land in trunk by 2.9.1

@scabug
Copy link
Author

scabug commented Jun 12, 2011

@paulp said:
What's the haps on this one? I ran the tests on it, came out smiling. Pull the trigger once in a while!

@scabug
Copy link
Author

scabug commented Jun 14, 2011

Commit Message Bot (anonymous) said:
(moors in r25087) closes #4547. parts now also looks in HasMethodMatching-style refinedtype's, so that the argument types of the method we're looking for contribute to the implicit scope.

review by rompf -- odersky may want to take a quick look and update the spec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants