Off the top of my head: Extension methods. "with" contexts. Scope functions (by letting you write your own). Many of the things done with kapt (e.g. typeclasses, not that there's a good way to do them in Kotlin). Spring-style autowiring (not part of Kotlin proper, but seemingly the idiomatic way to use it). The magic last parameter lambda syntax thing (by letting you implement the magnet pattern).

Scala implicits are used in a few different places, predominantly in library code where they can for example be used to derive instances of type classes. e.g. in circe:

  import io.circe.syntax._
  List(1, 2, 3).asJson

Where `asJson` requires an instance of an `Encoder`[1] and this Encoder can be derived with the help of implicits.

For you as a normal user, the two common places where you might use implicits are (1) for implicit classes providing syntactic sugar:

  // original
  def doSomething(a: A): B = ???
  val a: A = ???
  val b = doSomething(a)

  // with implicits
  implicit class AImplicits(a: A) {
    def doSomething: B = ???
  }
  val a: A = ???
  val b = a.doSomething

and for (2) implicit conversions. These are a foot-gun, so should be used in limited circumstances. At work, we use case classes in data pipelines then convert these to avro classes on save; there's lots of ways to do this, but as an example if you have an `Optional[Int]` and your avro constructor requires a nullable java `Integer` then `JavaConverters` won't save you and you'll need something like:

  implicit def optIntToInteger(optI: Option[Int]): java.lang.Integer = optI.map(Int.box).orNull

[1] https://circe.github.io/circe/api/io/circe/syntax/package$$E...

Scala 3 takes the most common use cases for implicits and makes them more ergonomic. Implicits are still in the language, but not exposed as concept.

Odersky called the approach for Scala 3 "intent over mechanism."

CanBuildFrom is gone in the 2.13 collections rewrite

No it does not. A for-comprehension just requires that map/flatMap methods are available. No implicits or CanBuildFrom needed.

I think that's were it comes from: people that briefly worked with Scala in the past.

At some point it was true, but nowadays the problem is solved because IDEs will show you were an implicit is used and where it comes from. Without that, it was indeed more difficult - but also not more difficult than Java's reflection or DI (where you had and have even less help).

> When first reading through code you don't really know if that function call you eyed over really has the params you think it does.

Yeah, but don't you feel the same pain when using Spring's autowiring? Or python's (or C++ template) default arguments? Or dynamic method dispatching in any OO language, where you don't know what method you actually call? Or late bindings?

I don't see how implicits' implicitness is significantly worse than any other kind of implicitness common in other language.