How to override an implicit value?

Question

Suppose I have the code:

class A(implicit s:String = "foo"){println(s)}

object X {
   implicit val s1 = "hello"
}
object Y {
   import X._
   // do something with X
   implicit val s2 = "hi"
   val a = new A
}

I get the error:

<console>:14: error: ambiguous implicit values:
 both value s2 in object Y of type => String
 and value s1 in object X of type => String
 match expected type String
           val a = new A

Is there any way I can tell Scala to use the value s2 in Y? (if I rename s2 to s1, it works as expected but that is not what I want).

Another solution is to not do import X._, again something I'm trying to avoid.

Guffaw

Answer 1

Another thing you can do is to import everything but s1: import X.{s1 => _, _}.

Wiburg

Thanks for the answer! Probably the best one till now. – Guffaw

Answer 2

I agree with the other answer that explicitly providing the implicit in these types of situations is preferred, but if you insist on wanting to 'downgrade' the other implicit so it's no longer treated as an implicit then it is actually possible:

class A(implicit s:String = "foo"){println(s)}

object X {
  implicit val s1 = "hello"
}
object Y {
  import X._
  val s1 = X.s1 //downgrade to non-implicit

  // do something with X
  implicit val s2 = "hi"
  val a = new A
}

Again, this is a bit hackish, but it works.

Mythopoeia

Agree.. A bit hackish but does the job. – Guffaw

Answer 3

Try:

new A()(s2)

This should override the implicit parameter through er explicitly providing it.

Linoel

That defeats the purpose of using the implicit parameter. I have new A in several places and I'd rather just remove the implicit then. – Guffaw

@Guffaw I just don't see how you are going to be able to keep the wildcard import and not override the explicit at least once... – Linoel

Using an implicit for something small and objective like strings does not make sense in the first place. – Silda

@SarveshKumarSingh I agree. The String is just for the sake of example. In my actual code its quite a complex object. – Guffaw

@Guffaw What happens if you name s2 the same as s1? Just out of curiosity – Linoel

And you have multiple instances of that complex object in scope. Implicits generally make sense for Helper-functions, typeclass abstract evidences such as Monads or large and meant to be reused large objects like ActorSystem. – Silda

@Others: When I use s1, the behaviour is what I want and expected: It overrides the old one. However, I don't want the names to be the same due to other reasons. – Guffaw