Scala Programming Language
  1. Scala Programming Language
  2. SI-4547

Failure of implicit conversion from {int, long, double} to {BigInt, BigDecimal}

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None
    • Environment:

      implicits BigInt BigDecimal

      Description

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

        Activity

        Hide
        Paul Phillips added a comment -

        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)
                         ^
        
        
        Show
        Paul Phillips added a comment - 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) ^
        Hide
        Paul Phillips added a comment -

        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.

        Show
        Paul Phillips added a comment - 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.
        Hide
        Paul Phillips added a comment -

        I agree that this presents a usability problem.

        Show
        Paul Phillips added a comment - I agree that this presents a usability problem.
        Hide
        Adriaan Moors added a comment -

        fix pending

        Show
        Adriaan Moors added a comment - fix pending
        Hide
        Harrison Klaperman added a comment -

        Thanks for the really quick turnaround on this. Is the planned solution to add conversions to Predef?

        Show
        Harrison Klaperman added a comment - Thanks for the really quick turnaround on this. Is the planned solution to add conversions to Predef?
        Hide
        Adriaan Moors added a comment -

        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

        Show
        Adriaan Moors added a comment - 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
        Hide
        Paul Phillips added a comment -

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

        Show
        Paul Phillips added a comment - What's the haps on this one? I ran the tests on it, came out smiling. Pull the trigger once in a while!
        Hide
        Commit Message Bot added a comment -

        (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

        Show
        Commit Message Bot added a comment - (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

          People

          • Assignee:
            Adriaan Moors
            Reporter:
            Harrison Klaperman
            TracCC:
            Paul Phillips, Seth Tisue
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development