Add scala.Conversion

as a replacement for DottyPredef.ImplicitConversion

Author: odersky

compiler/src/dotty/tools/dotc/core/Definitions.scala

@@ -389,9 +389,6 @@ class Definitions {
 
   def DottyPredefModule(implicit ctx: Context): Symbol = DottyPredefModuleRef.symbol
 
-    lazy val Predef_ImplicitConversionR: TypeRef = DottyPredefModule.requiredClass("ImplicitConversion").typeRef
-    def Predef_ImplicitConversion(implicit ctx: Context): Symbol = Predef_ImplicitConversionR.symbol
-
   lazy val DottyArraysModuleRef: TermRef = ctx.requiredModuleRef("dotty.runtime.Arrays")
   def DottyArraysModule(implicit ctx: Context): Symbol = DottyArraysModuleRef.symbol
     def newGenericArrayMethod(implicit ctx: Context): TermSymbol = DottyArraysModule.requiredMethod("newGenericArray")
@@ -592,6 +589,8 @@ class Definitions {
   def StringBuilderClass(implicit ctx: Context): ClassSymbol = StringBuilderType.symbol.asClass
   lazy val MatchErrorType: TypeRef         = ctx.requiredClassRef("scala.MatchError")
   def MatchErrorClass(implicit ctx: Context): ClassSymbol = MatchErrorType.symbol.asClass
+  lazy val ConversionType: TypeRef = ctx.requiredClass("scala.Conversion").typeRef
+  def ConversionClass(implicit ctx: Context): ClassSymbol = ConversionType.symbol.asClass
 
   lazy val StringAddType: TypeRef          = ctx.requiredClassRef("scala.runtime.StringAdd")
   def StringAddClass(implicit ctx: Context): ClassSymbol = StringAddType.symbol.asClass

compiler/src/dotty/tools/dotc/typer/Checking.scala

@@ -622,7 +622,7 @@ trait Checking {
       if !mt.isImplicitMethod && !sym.is(Synthetic) => // it's a conversion
         check()
       case AppliedType(tycon, _)
-      if tycon.derivesFrom(defn.Predef_ImplicitConversion) && !sym.is(Synthetic) =>
+      if tycon.derivesFrom(defn.ConversionClass) && !sym.is(Synthetic) =>
         check()
       case _ =>
     }

compiler/src/dotty/tools/dotc/typer/Implicits.scala

@@ -126,9 +126,9 @@ object Implicits {
               // this in Predef:
               //
               //    implicit def convertIfConforms[A, B](x: A)(implicit ev: A <:< B): B = ev(a)
-              //    implicit def convertIfConverter[A, B](x: A)(implicit ev: ImplicitConversion[A, B]): B = ev(a)
+              //    implicit def convertIfConverter[A, B](x: A)(implicit ev: Conversion[A, B]): B = ev(a)
               //
-              // (Once `<:<` inherits from `ImplicitConversion` we only need the 2nd one.)
+              // (Once `<:<` inherits from `Conversion` we only need the 2nd one.)
               // But clauses like this currently slow down implicit search a lot, because
               // they are eligible for all pairs of types, and therefore are tried too often.
               // We emulate instead these conversions directly in the search.
@@ -138,7 +138,7 @@ object Implicits {
               // We keep the old behavior under -language:Scala2.
               val isFunctionInS2 =
                 ctx.scala2Mode && tpw.derivesFrom(defn.FunctionClass(1)) && ref.symbol != defn.Predef_conforms
-              val isImplicitConversion = tpw.derivesFrom(defn.Predef_ImplicitConversion)
+              val isImplicitConversion = tpw.derivesFrom(defn.ConversionClass)
               val isConforms = // An implementation of <:< counts as a view, except that $conforms is always omitted
                   tpw.derivesFrom(defn.Predef_Conforms) && ref.symbol != defn.Predef_conforms
               val hasExtensions = resType match {

docs/docs/reference/changed-features/implicit-conversions-spec.md

@@ -9,16 +9,17 @@ An implicit conversion, or _view_, from type `S` to type `T` is
 defined by either:
 
 - An `implicit def` which has type `S => T` or `(=> S) => T`
-- An implicit value which has type `ImplicitConversion[S, T]`
+- An implicit value which has type `Conversion[S, T]`
 
-The standard library defines an abstract class `ImplicitConversion`:
+The standard library defines an abstract class `Conversion`:
 
 ```scala
-abstract class ImplicitConversion[-T, +U] extends Function1[T, U]
+package scala
+@java.lang.FunctionalInterface
+abstract class Conversion[-T, +U] extends Function1[T, U]
 ```
 
-Function literals are automatically converted to `ImplicitConversion`
-values.
+Function literals are automatically converted to `Conversion` values.
 
 Views are applied in three situations:
 
@@ -60,14 +61,14 @@ val x: String = 0 // Compiles in Scala2 (uses `conv1`),
 
 In Scala 2, implicit values of a function type would be considered as
 potential views. In Scala 3, these implicit value need to have type
-`ImplicitConversion`:
+`Conversion`:
 
 ```scala
 // Scala 2:
 def foo(x: Int)(implicit conv: Int => String): String = x
 
 // Becomes with Scala 3:
-def foo(x: Int)(implicit conv: ImplicitConversion[Int, String]): String = x
+def foo(x: Int)(implicit conv: Conversion[Int, String]): String = x
 
 // Call site is unchanged:
 foo(4)(_.toString)
@@ -76,7 +77,7 @@ foo(4)(_.toString)
 implicit val myConverter: Int => String = _.toString
 
 // Becomes with Scala 3:
-implicit val myConverter: ImplicitConversion[Int, String] = _.toString
+implicit val myConverter: Conversion[Int, String] = _.toString
 ```
 
 Note that implicit conversions are also  affected by the [changes to
@@ -85,7 +86,7 @@ Scala 3.
 
 ## Motivation for the changes
 
-The introduction of `ImplicitConversion` in Scala 3 and the decision to
+The introduction of `Conversion` in Scala 3 and the decision to
 restrict implicit values of this type to be considered as potential
 views comes from the desire to remove surprising behavior from the
 language:
@@ -101,12 +102,12 @@ This snippet contains a type error. The right hand side of `val x`
 does not conform to type `String`. In Scala 2, the compiler will use
 `m` as an implicit conversion from `Int` to `String`, whereas Scala 3
 will report a type error, because Map isn't an instance of
-`ImplicitConversion`.
+`Conversion`.
 
 ## Migration path
 
 Implicit values that are used as views should see their type changed
-to `ImplicitConversion`.
+to `Conversion`.
 
 For the migration of implicit conversions that are affected by the
 changes to implicit resolution, refer to the [Changes in Implicit

docs/docs/reference/changed-features/implicit-conversions.md

@@ -19,7 +19,7 @@ case).
 This conversion can be either:
 
 1. An `implicit def` of type `T => S` or `(=> T) => S`
-1. An implicit value of type `ImplicitConversion[T, S]`
+1. An implicit value of type `scala.Conversion[T, S]`
 
 Defining an implicit conversion will emit a warning unless the import
 `scala.language.implicitConversions` is in scope, or the flag
@@ -37,14 +37,14 @@ implicit def int2Integer(x: Int): java.lang.Integer =
   x.asInstanceOf[java.lang.Integer]
 ```
 
-The second example shows how to use `ImplicitConversion` to define an
+The second example shows how to use `Conversion` to define an
 `Ordering` for an arbitrary type, given existing `Ordering`s for other
 types:
 
 ```scala
 import scala.language.implicitConversions
 implicit def ordT[T, S](
-  implicit conv: ImplicitConversion[T, S],
+  implicit conv: Conversion[T, S],
            ordS: Ordering[S]
   ): Ordering[T] = {
   // `ordS` compares values of type `S`, but we can convert from `T` to `S`
@@ -54,7 +54,7 @@ implicit def ordT[T, S](
 class A(val x: Int) // The type for which we want an `Ordering`
 
 // Convert `A` to a type for which an `Ordering` is available:
-implicit val AToInt: ImplicitConversion[A, Int] = _.x
+implicit val AToInt: Conversion[A, Int] = _.x
 
 implicitly[Ordering[Int]] // Ok, exists in the standard library
 implicitly[Ordering[A]] // Ok, will use the implicit conversion from

docs/docs/reference/instances/discussion/replacing-implicits.md

@@ -79,19 +79,19 @@ lazy implicit val intOrd2: Ord[Int] = new IntOrd
 
 ## Implicit Conversions and Classes
 
-The only use cases that are not yet covered by the proposal are implicit conversions and implicit classes. We do not propose to use `instance` in place of `implicit` for these, since that would bring back the uncomfortable similarity between implicit conversions and parameterized implicit aliases. However, there is a way to drop implicit conversions entirely. Scala 3 already [defines](https://github.com/lampepfl/dotty/pull/2065) a class `ImplicitConversion` whose instances are available as implicit conversions.
+The only use cases that are not yet covered by the proposal are implicit conversions and implicit classes. We do not propose to use `instance` in place of `implicit` for these, since that would bring back the uncomfortable similarity between implicit conversions and parameterized implicit aliases. However, there is a way to drop implicit conversions entirely. Scala 3 already [defines](https://github.com/lampepfl/dotty/pull/2065) a class `Conversion` whose instances are available as implicit conversions.
 ```scala
-  abstract class ImplicitConversion[-T, +U] extends Function1[T, U]
+  abstract class Conversion[-T, +U] extends Function1[T, U]
 ```
 One can define all implicit conversions as instances of this class. E.g.
 ```scala
-instance StringToToken of ImplicitConversion[String, Token] {
+instance StringToToken of Conversion[String, Token] {
   def apply(str: String): Token = new KeyWord(str)
 }
 ```
 The fact that this syntax is more verbose than simple implicit defs could be a welcome side effect since it might dampen any over-enthusiasm for defining implicit conversions.
 
-That leaves implicit classes. Most use cases of implicit classes are probably already covered by extension methods. For the others, one could always fall back to a pair of a regular class and an `ImplicitConversion` instance. It would be good to do a survey to find out how many classes would be affected.
+That leaves implicit classes. Most use cases of implicit classes are probably already covered by extension methods. For the others, one could always fall back to a pair of a regular class and an `Conversion` instance. It would be good to do a survey to find out how many classes would be affected.
 
 ## Summoning an Instance
 

docs/docs/reference/instances/instance-defs.md

@@ -29,7 +29,7 @@ instance ListOrd[T: Ord] for Ord[List[T]] {
 }
 ```
 
-Instance can be seen as shorthands for what is currently expressed with implicit object and method definitions.
+Instance definitions can be seen as shorthands for what is currently expressed with implicit object and method definitions.
 For instance, the definition of instance `IntOrd` above defines an implicit value of type `Ord[Int]`. It is hence equivalent
 to the following implicit object definition:
 ```scala

library/src/dotty/DottyPredef.scala

@@ -4,25 +4,6 @@ import scala.forceInline
 
 object DottyPredef {
 
-  /** A class for implicit values that can serve as implicit conversions
-   *  The implicit resolution algorithm will act as if there existed
-   *  the additional implicit definition:
-   *
-   *    def $implicitConversion[T, U](x: T)(c: ImplicitConversion[T, U]): U = c(x)
-   *
-   *  However, the presence of this definition would slow down implicit search since
-   *  its outermost type matches any pair of types. Therefore, implicit search
-   *  contains a special case in `Implicits#discardForView` which emulates the
-   *  conversion in a more efficient way.
-   *
-   *  Note that this is a SAM class - function literals are automatically converted
-   *  to `ImplicitConversion` values.
-   *
-   *  Also note that in bootstrapped dotty, `Predef.<:<` should inherit from
-   *  `ImplicitConversion`. This would cut the number of special cases in
-   *  `discardForView` from two to one.
-   */
-  abstract class ImplicitConversion[-T, +U] extends Function1[T, U]
 
   @forceInline final def assert(assertion: => Boolean, message: => Any): Unit = {
     if (!assertion)

library/src/scala/Conversion.scala

@@ -0,0 +1,22 @@
+package scala
+
+/** A class for implicit values that can serve as implicit conversions
+*  The implicit resolution algorithm will act as if there existed
+*  the additional implicit definition:
+*
+*    def $implicitConversion[T, U](x: T)(c: Conversion[T, U]): U = c(x)
+*
+*  However, the presence of this definition would slow down implicit search since
+*  its outermost type matches any pair of types. Therefore, implicit search
+*  contains a special case in `Implicits#discardForView` which emulates the
+*  conversion in a more efficient way.
+*
+*  Note that this is a SAM class - function literals are automatically converted
+*  to the `Conversion` values.
+*
+*  Also note that in bootstrapped dotty, `Predef.<:<` should inherit from
+*  `Conversion`. This would cut the number of special cases in `discardForView`
+*  from two to one.
+*/
+@java.lang.FunctionalInterface
+abstract class Conversion[-T, +U] extends Function1[T, U]

tests/neg-custom-args/impl-conv/A.scala

@@ -3,7 +3,7 @@ package implConv
 object A {
 
   implicit def s2i(x: String): Int = Integer.parseInt(x) // error: feature
-  implicit val i2s: ImplicitConversion[Int, String] = _.toString // error: feature
+  implicit val i2s: Conversion[Int, String] = _.toString // error: feature
 
   implicit class Foo(x: String) {
     def foo = x.length

tests/pos/reference/instances.scala

@@ -146,7 +146,7 @@ object Instances extends Common {
 
   class Token(str: String)
 
-  instance StringToToken of ImplicitConversion[String, Token] {
+  instance StringToToken of Conversion[String, Token] {
     def apply(str: String): Token = new Token(str)
   }
 

tests/run/t8280.scala

@@ -74,14 +74,14 @@ object Moop3 {
       // Dotty deviation. This fails for Dotty with ambiguity error for similar reasons as ob1.
   }
   object ob2 {
-    implicit val f1: ImplicitConversion[Int, String]  = _ => "Int"
+    implicit val f1: Conversion[Int, String]  = _ => "Int"
     implicit def f2(x: Long): String = "Long"
 
     println(5: String)
   }
   object ob3 {
-    implicit val f1: ImplicitConversion[Int, String]  = _ => "Int"
-    implicit val f2: ImplicitConversion[Long, String] = _ => "Long"
+    implicit val f1: Conversion[Int, String]  = _ => "Int"
+    implicit val f2: Conversion[Long, String] = _ => "Long"
 
     println((5: Int): String)
     // println(5: String)  // error: ambiguity, since both f1 and f2 are applicable to 5.