Method overloading in implicit class - scala

I'm using a class (that I cannot modify) containing a method which receives a value of type Any as parameter, like the following example:
class Foo(value: Int) {
def +(other: Any): Foo = ???
}
I would like to add a custom implementation for the method +() when it's used with a specific type. I would expect to be able to do something like:
implicit class RichFoo(foo: Foo) {
def +(other: Int): Foo = ???
}
// or
implicit class RichFoo(foo: Foo) {
def +[T <: Bar](other: T): T = ???
}
However, these approaches don't work.
Is it possible to do without extending the original class?

No.
To the compiler, implicit conversions and other rewrite rules (like those around Dynamic) are a "last resort" of sorts. They are only applied if code does not already typecheck as-is. When you do foo + x, the compiler already knows that + takes Any, so it doesn't even try to look for implicits. If you did foo - x, and Foo had no - of the correct type, only then would the compiler search for a conversion.
Instead, you can create a method with a new name, maybe add, that is not present in Foo but is present in RichFoo. This will not, however, protect you from doing foo + 1 instead of foo add 1, since both methods are valid.
implicit class RichFoo(foo: Foo) {
def add(other: Int): Foo = ???
}

You can use a phantom type to track what is convertible.
scala> trait Tagged[B]
defined trait Tagged
scala> type Of[+A, B] = A with Tagged[B]
defined type alias Of
scala> class Tagger[B] { def apply[A](a: A): A Of B = a.asInstanceOf[A Of B] }
defined class Tagger
scala> object tag { def apply[B]: Tagger[B] = new Tagger[B] }
defined object tag
The given thing:
scala> case class C(i: Int) { def +(x: Any): C = C(i + x.toString.toInt) }
defined class C
and a marker trait:
scala> trait CC
defined trait CC
Normally:
scala> C(42) + "17"
res0: C = C(59)
This works:
scala> val cc = tag[CC](C(42))
cc: Of[C,CC] = C(42)
But not this:
scala> val cc = tag[CC](C(42): Any)
java.lang.ClassCastException: C cannot be cast to Tagged
... 29 elided
Maybe this:
scala> val cc = tag[CC](C(42): Serializable)
cc: Of[Serializable,CC] = C(42)
Then:
scala> implicit class XC(v: Serializable Of CC) {
| def +(x: Any): C Of CC = tag[CC] {
| println("OK")
| v.asInstanceOf[C] + x
| }}
defined class XC
Abnormally:
scala> val valueAdded = cc + "17"
OK
valueAdded: Of[C,CC] = C(59)
There's surely a better way to do this:
scala> implicit def untagit(x: Serializable Of CC): C Of CC = tag[CC](x.asInstanceOf[C])
untagit: (x: Of[Serializable,CC])Of[C,CC]
scala> cc.i
res9: Int = 42
because that ruins it:
scala> val res: C = cc + "17"
<console>:18: error: type mismatch;
found : <refinement>.type (with underlying type Of[Serializable,CC])
required: ?{def +(x$1: ? >: String("17")): ?}
Note that implicit conversions are not applicable because they are ambiguous:
both method XC of type (v: Of[Serializable,CC])XC
and method untagit of type (x: Of[Serializable,CC])Of[C,CC]
are possible conversion functions from <refinement>.type to ?{def +(x$1: ? >: String("17")): ?}
val res: C = cc + "17"
^
<console>:18: error: value + is not a member of Of[Serializable,CC]
val res: C = cc + "17"
^

Related

How to correctly use ambiguous implicits for type negation in Scala

Ultimately what I want to do is provide one implementation of a type class for some specific type T and another implementation for all other types which are not T. I thought (perhaps incorrectly) that the easiest way to do this would be to try type negation via ambiguous implicits as described in this question. However, if I accidentally omit the implicit type class declaration, my code will still compile (should it?) but include bugs as only one of the implementations is used.
This is how the context bound is defined:
scala> trait NotAnInt[A]
defined trait NotAnInt
scala> implicit def everythingIsNotAnInt[A]: NotAnInt[A] = new NotAnInt[A] {}
everythingIsNotAnInt: [A]=> NotAnInt[A]
scala> implicit def intsAreInts1: NotAnInt[Int] = ???
intsAreInts1: NotAnInt[Int]
scala> implicit def intsAreInts2: NotAnInt[Int] = ???
intsAreInts2: NotAnInt[Int]
scala> implicit def nothingsAreInts1: NotAnInt[Nothing] = ???
nothingsAreInts1: NotAnInt[Nothing]
scala> implicit def nothingsAreInts2: NotAnInt[Nothing] = ???
nothingsAreInts2: NotAnInt[Nothing]
At this point NotAnInt[T] is summonable for all T except Int/Nothing:
scala> implicitly[NotAnInt[String]]
res3: NotAnInt[String] = $anon$1#1a24fe09
scala> implicitly[NotAnInt[Int]]
<console>:16: error: ambiguous implicit values:
both method intsAreInts1 of type => NotAnInt[Int]
and method intsAreInts2 of type => NotAnInt[Int]
match expected type NotAnInt[Int]
implicitly[NotAnInt[Int]]
^
scala> implicitly[NotAnInt[Nothing]]
<console>:18: error: ambiguous implicit values:
both method nothingsAreInts1 of type => NotAnInt[Nothing]
and method nothingsAreInts2 of type => NotAnInt[Nothing]
match expected type NotAnInt[Nothing]
implicitly[NotAnInt[Nothing]]
^
Now I have my NotAnInt context bound defined I can create my type class with its implementations:
scala> trait IntChecker[A] { def isInt(): Boolean }
defined trait IntChecker
scala> implicit val intIntChecker: IntChecker[Int] = new IntChecker[Int] { override def isInt = true }
intIntChecker: IntChecker[Int] = $anon$1#585dd35c
scala> implicit def otherIntChecker[A: NotAnInt]: IntChecker[A] = new IntChecker[A] { override def isInt = false }
otherIntChecker: [A](implicit evidence$1: NotAnInt[A])IntChecker[A]
This type class can be used as expected:
scala> def printIntStatus[T: IntChecker](t: T): Unit = { println(implicitly[IntChecker[T]].isInt()) }
printIntStatus: [T](t: T)(implicit evidence$1: IntChecker[T])Unit
scala> printIntStatus(3)
true
scala> printIntStatus("three")
false
However, the following also compiles:
scala> def printIntStatusWithBug[T](t: T): Unit = { println(implicitly[IntChecker[T]].isInt()) }
printIntStatusWithBug: [T](t: T)Unit
scala> printIntStatusWithBug(3)
false
scala> printIntStatusWithBug("three")
false
I would not expect this second function to compile as there should be no implicit IntChecker[T] available. I expect everythingIsNotAnInt is the cause of this problem but I can't think of a way around this.
I'm interested in why this approach fails as well as alternative methods on how to achieve the same thing. Thank you.
Consider the following alternative implementation (which uses Sabin's type inequalities)
trait =!=[A, B]
implicit def neq[A, B] : A =!= B = null
implicit def neqAmbig1[A] : A =!= A = null
implicit def neqAmbig2[A] : A =!= A = null
trait IntChecker[A] {
def isInt(): Boolean
}
object IntChecker {
import scala.reflect.ClassTag
implicit val intIntChecker: IntChecker[Int] = () => true
implicit def notIntIntChecker[T: ClassTag](implicit ev: T =!= Int): IntChecker[T] = () => false
}
def printIntStatus[T: IntChecker](t: T) = implicitly[IntChecker[T]].isInt()
import IntChecker._
printIntStatus(3)
printIntStatus("three")
which outputs
res0: Boolean = true
res1: Boolean = false
however the buggy implementation where we forget IntChecker bound
def printIntStatusWithBug[T](t: T) = implicitly[IntChecker[T]].isInt()
should not compile due to having T: ClassTag bound in
implicit def notIntIntChecker[T: ClassTag](implicit ev: T =!= Int)
giving compiler error
could not find implicit value for parameter e: IntChecker[T]
def printIntStatusWithBug[T](t: T) = implicitly[IntChecker[T]].isInt()
^

How to Rewrite Function Using Context Bounds?

Given the following Addable type-class:
scala> trait Addable[A] {
| def add(x: A): A
| }
defined trait Addable
I created an instance for Int:
scala> class AddInt(x: Int) extends Addable[Int] {
| override def add(y: Int) = x + y
| }
defined class AddInt
Then, I created an implicit AddInt:
scala> implicit val addInt: AddInt = new AddInt(10)
addInt: AddInt = AddInt#1f010bf0
Lastly, I defined a generic function, foo:
scala> def foo[A](x: A)(implicit ev: Addable[A]): A = ev.add(x)
foo: [A](x: A)(implicit ev: Addable[A])A
Now, I can call it with the successful implicit resolution of addInt:
scala> foo(10)
res0: Int = 20
How can I define foo using the context bound notation?
example:
def foo[A : Addable]...?
Just define the method like you do in your own example:
def foo[A : Addable](x: A) = implicitly[Addable[A]].add(x)

Alternative Syntax When Defining Implicit?

Given the following:
scala> trait Foo { def get: String = "get" }
defined trait Foo
I implemented it and made an implicit:
scala> case class FooImpl(x: String) extends Foo {
| override def get = s"got $x"
| }
defined class FooImpl
scala> implicit val fooImpl = FooImpl("yo")
fooImpl: FooImpl = FooImpl(yo)
Lastly, I tried to write a method that implicitly resolves a Foo, returning get on that implicitly resolved class.
scala> def f[A: Foo](x: A) = x.get
<console>:11: error: Foo does not take type parameters
def f[A: Foo](x: A) = x.get
^
<console>:11: error: value get is not a member of type parameter A
def f[A: Foo](x: A) = x.get
^
But I got the above errors.
So I re-wrote it using the implicit keyword:
scala> def f(implicit x: Foo): String = x.get
f: (implicit x: Foo)String
scala> f
res0: String = got yo
Is it possible to re-write this example to not explicitly specify the implicit keyword?
Note - it's possible that I'm confusing this notation with TypeTag under the section, Using a Context bound of a Type Parameter.
You are using the wrong syntax, what you want is an upper bound:
scala> def f[A <: Foo](x: A) = x.get
f: [A <: Foo](x: A)String
Where you're saying that A is a subtype of Foo and that tells the compiler that A does have a method called get.
The syntax you're using (:) means that there's an implicit conversion from A to Foo[A], the problem is that Foo doesn't take a type parameter, you can also check it into the REPL where the column syntax is translated to an implicit parameter:
scala> trait Foo2[T]
defined trait Foo2
scala> def g[T: Foo2](x: Int): Int = x
g: [T](x: Int)(implicit evidence$1: Foo2[T])Int

Explain "this.type" as a return type of various API methods

I am looking though the source code of the Promise[T] trait from the scala.concurrent package.
So here is the method declaration where I need your help in one place:
trait Promise[T] {
....
def complete(result: Try[T]): this.type =
if (tryComplete(result)) this else throw new IllegalStateException("Promise already completed.")
....
}
I do not really understand how to interpret the this.type as a complete method return type. Why not simple the return type could be Promise[T] ?
Sorry if my question will seem too simple for someone, I am just learning this stuff.
this.type is necessary in a path dependent context:
scala> class A { class B; def f(b: B): A = this }
defined class A
scala> val a1 = new A; val b1 = new a1.B; val a2 = new A
a1: A = A#721f1edb
b1: a1.B = A$B#5922f665
a2: A = A#65e8e9b
scala> a1.f(b1)
res6: A = A#721f1edb
scala> a2.f(b1)
<console>:12: error: type mismatch;
found : a1.B
required: a2.B
a2.f(b1)
^
Path dependent means that the compiler knows that types belong together. In the above example one can see that new a1.B produces a value of type a1.B and not only B. However, this does not work:
scala> a1.f(b1).f(b1)
<console>:11: error: type mismatch;
found : a1.B
required: _2.B where val _2: A
a1.f(b1).f(b1)
^
The problem is that the return type of f is A, which has no information anymore about the path dependent relationship. Returning this.type instead tells the compiler that the return type fulfills this relationship:
scala> class A { class B; def f(b: B): this.type = this }
defined class A
scala> val a1 = new A; val b1 = new a1.B; val a2 = new A
a1: A = A#60c40d9c
b1: a1.B = A$B#6759ae65
a2: A = A#30c89de5
scala> a1.f(b1).f(b1)
res10: a1.type = A#60c40d9c
I suspect the reason is supporting inheritance.
Consider this simple example
trait Foo[A] {
def foo: Foo[A] = this
}
trait Bar[A] extends Foo[A]
Now let's try it out
scala> (new Foo[Int]{}).foo
res0: Foo[Int] = $anon$1#7f0aa670
scala> (new Bar[Int]{}).foo
res1: Foo[Int] = $anon$1#4ee2dd22
As you can see, the method foo returns a Foo[Int] in both cases, and that's because you returned the "hardcoded" type Foo[T] in the method definition.
If you instead do
trait Foo[A] {
def foo: this.type = this
}
trait Bar[A] extends Foo[A]
then the returned type depends on the instance you're invoking foo on:
scala> (new Foo[Int]{}).foo
res2: Foo[Int] = $anon$1#1391e025
scala> (new Bar[Int]{}).foo
res3: Bar[Int] = $anon$1#4142991e

What is the Scala identifier "implicitly"?

I have seen a function named implicitly used in Scala examples. What is it, and how is it used?
Example here:
scala> sealed trait Foo[T] { def apply(list : List[T]) : Unit }; object Foo {
| implicit def stringImpl = new Foo[String] {
| def apply(list : List[String]) = println("String")
| }
| implicit def intImpl = new Foo[Int] {
| def apply(list : List[Int]) = println("Int")
| }
| } ; def foo[A : Foo](x : List[A]) = implicitly[Foo[A]].apply(x)
defined trait Foo
defined module Foo
foo: [A](x: List[A])(implicit evidence$1: Foo[A])Unit
scala> foo(1)
<console>:8: error: type mismatch;
found : Int(1)
required: List[?]
foo(1)
^
scala> foo(List(1,2,3))
Int
scala> foo(List("a","b","c"))
String
scala> foo(List(1.0))
<console>:8: error: could not find implicit value for evidence parameter of type
Foo[Double]
foo(List(1.0))
^
Note that we have to write implicitly[Foo[A]].apply(x) since the compiler thinks that implicitly[Foo[A]](x) means that we call implicitly with parameters.
Also see How to investigate objects/types/etc. from Scala REPL? and Where does Scala look for implicits?
implicitly is avaliable in Scala 2.8 and is defined in Predef as:
def implicitly[T](implicit e: T): T = e
It is commonly used to check if an implicit value of type T is available and return it if such is the case.
Simple example from retronym's presentation:
scala> implicit val a = "test" // define an implicit value of type String
a: java.lang.String = test
scala> val b = implicitly[String] // search for an implicit value of type String and assign it to b
b: String = test
scala> val c = implicitly[Int] // search for an implicit value of type Int and assign it to c
<console>:6: error: could not find implicit value for parameter e: Int
val c = implicitly[Int]
^
Here are a few reasons to use the delightfully simple method implicitly.
To understand/troubleshoot Implicit Views
An Implicit View can be triggered when the prefix of a selection (consider for example, the.prefix.selection(args) does not contain a member selection that is applicable to args (even after trying to convert args with Implicit Views). In this case, the compiler looks for implicit members, locally defined in the current or enclosing scopes, inherited, or imported, that are either Functions from the type of that the.prefix to a type with selection defined, or equivalent implicit methods.
scala> 1.min(2) // Int doesn't have min defined, where did that come from?
res21: Int = 1
scala> implicitly[Int => { def min(i: Int): Any }]
res22: (Int) => AnyRef{def min(i: Int): Any} = <function1>
scala> res22(1) //
res23: AnyRef{def min(i: Int): Int} = 1
scala> .getClass
res24: java.lang.Class[_] = class scala.runtime.RichInt
Implicit Views can also be triggered when an expression does not conform to the Expected Type, as below:
scala> 1: scala.runtime.RichInt
res25: scala.runtime.RichInt = 1
Here the compiler looks for this function:
scala> implicitly[Int => scala.runtime.RichInt]
res26: (Int) => scala.runtime.RichInt = <function1>
Accessing an Implicit Parameter Introduced by a Context Bound
Implicit parameters are arguably a more important feature of Scala than Implicit Views. They support the type class pattern. The standard library uses this in a few places -- see scala.Ordering and how it is used in SeqLike#sorted. Implicit Parameters are also used to pass Array manifests, and CanBuildFrom instances.
Scala 2.8 allows a shorthand syntax for implicit parameters, called Context Bounds. Briefly, a method with a type parameter A that requires an implicit parameter of type M[A]:
def foo[A](implicit ma: M[A])
can be rewritten as:
def foo[A: M]
But what's the point of passing the implicit parameter but not naming it? How can this be useful when implementing the method foo?
Often, the implicit parameter need not be referred to directly, it will be tunneled through as an implicit argument to another method that is called. If it is needed, you can still retain the terse method signature with the Context Bound, and call implicitly to materialize the value:
def foo[A: M] = {
val ma = implicitly[M[A]]
}
Passing a subset of implicit parameters explicitly
Suppose you are calling a method that pretty prints a person, using a type class based approach:
trait Show[T] { def show(t: T): String }
object Show {
implicit def IntShow: Show[Int] = new Show[Int] { def show(i: Int) = i.toString }
implicit def StringShow: Show[String] = new Show[String] { def show(s: String) = s }
def ShoutyStringShow: Show[String] = new Show[String] { def show(s: String) = s.toUpperCase }
}
case class Person(name: String, age: Int)
object Person {
implicit def PersonShow(implicit si: Show[Int], ss: Show[String]): Show[Person] = new Show[Person] {
def show(p: Person) = "Person(name=" + ss.show(p.name) + ", age=" + si.show(p.age) + ")"
}
}
val p = Person("bob", 25)
implicitly[Show[Person]].show(p)
What if we want to change the way that the name is output? We can explicitly call PersonShow, explicitly pass an alternative Show[String], but we want the compiler to pass the Show[Int].
Person.PersonShow(si = implicitly, ss = Show.ShoutyStringShow).show(p)
Starting Scala 3 implicitly has been replaced with improved summon which has the advantage of being able to return a more precise type than asked for
The summon method corresponds to implicitly in Scala 2. It is
precisely the same as the the method in Shapeless. The difference
between summon (or the) and implicitly is that summon can return a
more precise type than the type that was asked for.
For example given the following type
trait F[In]:
type Out
def f(v: Int): Out
given F[Int] with
type Out = String
def f(v: Int): String = v.toString
implicitly method would summon a term with erased type member Out
scala> implicitly[F[Int]]
val res5: F[Int] = given_F_Int$#7d0e5fbb
scala> implicitly[res5.Out =:= String]
1 |implicitly[res5.Out =:= String]
| ^
| Cannot prove that res5.Out =:= String.
scala> val x: res5.Out = ""
1 |val x: res5.Out = ""
| ^^
| Found: ("" : String)
| Required: res5.Out
In order to recover the type member we would have to refer to it explicitly which defeats the purpose of having the type member instead of type parameter
scala> implicitly[F[Int] { type Out = String }]
val res6: F[Int]{Out = String} = given_F_Int$#7d0e5fbb
scala> implicitly[res6.Out =:= String]
val res7: res6.Out =:= String = generalized constraint
However summon defined as
def summon[T](using inline x: T): x.type = x
does not suffer from this problem
scala> summon[F[Int]]
val res8: given_F_Int.type = given_F_Int$#7d0e5fbb
scala> summon[res8.Out =:= String]
val res9: String =:= String = generalized constraint
scala> val x: res8.Out = ""
val x: res8.Out = ""
where we see type member type Out = String did not get erased even though we only asked for F[Int] and not F[Int] { type Out = String }. This can prove particularly relevant when chaining dependently typed functions:
The type summoned by implicitly has no Out type member. For this
reason, we should avoid implicitly when working with dependently typed
functions.
A "teach you to fish" answer is to use the alphabetic member index currently available in the Scaladoc nightlies. The letters (and the #, for non-alphabetic names) at the top of the package / class pane are links to the index for member names beginning with that letter (across all classes). If you choose I, e.g., you'll find the implicitly entry with one occurrence, in Predef, which you can visit from the link there.