Claro. Akka tiene un gran ejemplo de ello con respecto a sus Actores. Cuando estás dentro del método receive de un Actor, es posible que quieras enviar un mensaje a otro Actor. Al hacer esto, Akka agrupará (por defecto) el Actor actual como el sender del mensaje, así:

trait ScalaActorRef { this: ActorRef =>
  ...

  def !(message: Any)(implicit sender: ActorRef = null): Unit

  ...
}

El sender está implícito. En el Actor hay una definición que se parece a:

trait Actor {
  ...

  implicit val self = context.self

  ...
}

Esto crea el valor implícito dentro del alcance de su propio código, y le permite hacer cosas fáciles así:

someOtherActor ! SomeMessage

Ahora, puedes hacer esto también, si quieres:

someOtherActor.!(SomeMessage)(self)

O

someOtherActor.!(SomeMessage)(null)

O

someOtherActor.!(SomeMessage)(anotherActorAltogether)

Pero normalmente no lo hace. Solo mantiene el uso natural que es posible gracias a la definición de valor implícita en el rasgo Actor. Hay alrededor de un millón de otros ejemplos. Las clases de colección son enormes. Intente vagar por cualquier biblioteca Scala no trivial y encontrará un camión cargado.

Un ejemplo serían las operaciones de comparación en Traversable[A]. Por ejemplo, max o sort:

def max[B >: A](implicit cmp: Ordering[B]) : A

Estos solo se pueden definir con sensatez cuando hay una operación < en A. Por lo tanto, sin implicits tendríamos que suministrar el contexto Ordering[B] cada vez que nos gustaría utilizar esta función. (O abandone la comprobación estática de tipo dentro de max y corra el riesgo de un error de conversión en tiempo de ejecución.)

Sin embargo, si una comparación implícita tipo clase está en el alcance, por ejemplo, algunos Ordering[Int], podemos usarlo de inmediato o simplemente cambie el método de comparación proporcionando algún otro valor para el parámetro implícito.

Por supuesto, los implicitos pueden ser sombreados y, por lo tanto, puede haber situaciones en las que lo implícito real que está en el alcance no es lo suficientemente claro. Para usos simples de max o sort podría ser suficiente tener un orden fijo trait en Int y usar alguna sintaxis para verificar si este rasgo está disponible. Pero esto significaría que no podría haber rasgos adicionales y cada pieza de código tendría que usar los rasgos que se definieron originalmente.

Además:
Respuesta a la variable global comparación.

Creo que tienes razón en que en un código recortado como {[19]]}

implicit val num = 2
implicit val item = "Orange"
def shopping(implicit num: Int, item: String) = {
  "I’m buying "+num+" "+item+(if(num==1) "." else "s.")
}

scala> shopping
res: java.lang.String = I’m buying 2 Oranges.

Puede oler a variables globales podridas y malvadas. El punto crucial, sin embargo, es que solo puede haber una variable implícita por tipo en el alcance. Tu ejemplo con dos Ints no va a funcionar.

También, esto significa que prácticamente, las variables implícitas se emplean solo cuando hay una instancia primaria no necesariamente única pero distinta para un tipo. La referencia self de un actor es un buen ejemplo para tal cosa. El ejemplo de clase de tipo es otro ejemplo. Puede haber docenas de comparaciones algebraicas para cualquier tipo, pero hay una que es especial. (En otro nivel, el número de línea real en el código mismo también podría ser una buena variable implícita siempre y cuando use una variable muy distintiva tipo.)

Normalmente no se usan implicit s para los tipos cotidianos. Y con tipos especializados (como Ordering[Int]) no hay demasiado riesgo en seguirlos.

Otro buen uso general de los parámetros implícitos es hacer que el tipo de retorno de un método dependa del tipo de algunos de los parámetros que se le pasan. Un buen ejemplo, mencionado por Jens, es el framework de colecciones, y métodos como map, cuya firma completa generalmente es:

def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[GenSeq[A], B, That]): That

Tenga en cuenta que el tipo de retorno That está determinado por el mejor ajuste CanBuildFrom que el compilador puede encontrar.

Para otro ejemplo de esto, ver esa respuesta. Allí, el tipo de retorno de la el método Arithmetic.apply se determina de acuerdo con un cierto tipo de parámetro implícito (BiConverter).

Es fácil, solo recuerda:

• para declarar la variable a pasar como implícita también
• para declarar todos los parámetros implícitos después de los parámetros no implícitos en un ()

Por ejemplo

def myFunction(): Int = {
  implicit val y: Int = 33
  implicit val z: Double = 3.3

  functionWithImplicit("foo") // calls functionWithImplicit("foo")(y, z)
}

def functionWithImplicit(foo: String)(implicit x: Int, d: Double) = // blar blar

Basado en mi experiencia no hay un buen ejemplo real para el uso de parámetros implicita o implicita conversión.

El pequeño beneficio de usar implicits (sin necesidad de escribir explícitamente un parámetro o un tipo) es redundante en comparación con los problemas que crean.

Soy desarrollador desde hace 15 años, y he estado trabajando con scala durante los últimos 1.5 años.

He visto muchas veces errores que fueron causados por el desarrollador no consciente del hecho de que implicits se utilizan, y que una función específica realmente devuelve un tipo diferente que el especificado. Debido a la conversión implícita.

También escuché declaraciones diciendo que si no te gustan los implicitos, no los uses. Esto no es práctico en el mundo real ya que muchas veces se usan bibliotecas externas, y muchas de ellas están usando implicitos, por lo que su código usa implicitos, y puede que no sea consciente de eso. Puedes escribir un código que tenga:

import org.some.common.library.{TypeA, TypeB}

O:

import org.some.common.library._

Ambos códigos compilarán y ejecutar. Pero no siempre producirán los mismos resultados ya que la segunda versión importada implica una conversión que hará que el código se comporte de manera diferente.

El 'bug' que es causado por esto puede ocurrir mucho tiempo después de que el código fue escrito, en caso de que algunos valores que son afectados por esta conversión no fueron utilizados originalmente.

Una vez que encuentre el error, no es una tarea fácil encontrar la causa. Tienes que hacer una investigación profunda.

Aunque te sientas como un experto en scala una vez que haya encontrado el error y lo haya solucionado cambiando una declaración de importación, realmente perdió mucho tiempo precioso.

Otras razones por las que generalmente estoy en contra de los implicitos son:

• Hacen que el código sea difícil de entender (hay menos código, pero no sabes lo que está haciendo)
• Tiempo de compilación. el código scala compila mucho más lento cuando se usan implicitos.
• En la práctica, cambia el lenguaje de tipo estático a dinámico escribir. Es cierto que una vez que siga pautas de codificación muy estrictas puede evitar este tipo de situaciones, pero en el mundo real, no siempre es el caso. Incluso usando el IDE 'remove unused imports', puede causar que su código aún compile y se ejecute, pero no lo mismo que antes de eliminar las importaciones 'unused'.

No hay ninguna opción para compilar scala sin implicitos (si hay, por favor corríjame), y si hubiera una opción, ninguna de las bibliotecas comunes de scala de la comunidad tendría que compilar.

Por todas las razones anteriores, creo que los implicitos son una de las peores prácticas que utiliza el lenguaje scala.

Scala tiene muchas grandes características, y muchas no tan grandes.

Al elegir un lenguaje para un nuevo proyecto, los implicitos son una de las razones en contra de scala, no a favor de ella. En mi opinión.

Los parámetros implícitos se usan mucho en la API de colección. Muchas funciones obtienen un CanBuildFrom implícito, lo que garantiza que obtenga la mejor implementación de la colección de resultados.

Sin implicitos, o bien pasarías tal cosa todo el tiempo, lo que haría que el uso normal fuera engorroso. O use colecciones menos especializadas, lo que sería molesto porque significaría que pierde rendimiento/potencia.

Estoy comentando este post un poco tarde, pero he empezado a aprender scala últimamente. Daniel y otros han dado buenos antecedentes sobre la palabra clave implícita. Me daría dos centavos en variable implícita desde la perspectiva del uso práctico.

Scala es más adecuado si se usa para escribir códigos de Apache Spark. En Spark, tenemos el contexto de spark y muy probablemente la clase de configuración que puede obtener las claves/valores de configuración de un archivo de configuración.

Ahora, Si tengo un clase abstracta y si declaro un objeto de configuración y contexto spark de la siguiente manera: -

abstract class myImplicitClass {

implicit val config = new myConfigClass()

val conf = new SparkConf().setMaster().setAppName()
implicit val sc = new SparkContext(conf)

def overrideThisMethod(implicit sc: SparkContext, config: Config) : Unit
}

class MyClass extends myImplicitClass {

override def overrideThisMethod(implicit sc: SparkContext, config: Config){

/*I can provide here n number of methods where I can pass the sc and config 
objects, what are implicit*/
def firstFn(firstParam: Int) (implicit sc: SparkContext, config: Config){ 
    /*I can use "sc" and "config" as I wish: making rdd or getting data from cassandra, for e.g.*/
    val myRdd = sc.parallelize(List("abc","123"))
}
def secondFn(firstParam: Int) (implicit sc: SparkContext, config: Config){
 /*following are the ways we can use "sc" and "config" */

        val keyspace = config.getString("keyspace")
        val tableName = config.getString("table")
        val hostName = config.getString("host")
        val userName = config.getString("username")
        val pswd = config.getString("password")

    implicit val cassandraConnectorObj = CassandraConnector(....)
    val cassandraRdd = sc.cassandraTable(keyspace, tableName)
}

}
}

Como podemos ver en el código anterior, tengo dos objetos implícitos en mi clase abstracta, y he pasado esas dos variables implícitas como parámetros implícitos de función/método/definición. Creo que este es el mejor caso de uso que podemos representar en términos de uso de variables implícitas.