A missing replacement for Scala 2 implicits in Scala 3

[therealcisse]

Compiler version

Scala-3.0.0-RC1

Minimized code

Given the following code:

import scala.concurrent.Future

trait Req[A]
trait Response[A]

object Req {
  def async[F[_], A](fn: Req[A] => Response[A]): F[Response[A]] = ???
}

Scala 2

@main def Test() = {
  
  Req.async[Future, Int] {  implicit req =>
    
   val r = summon[Req[A]]
   assert(r eq req)
    ???
  }
  
  
}

Scala 3:

Doesn't compile. No easy way to make req implicit.

@main def Test() = {
  
  // Req.async[Future, Int] {  given req => // error
  // Req.async[Future, Int] {  req : given Req[A] => // error    
  // Req.async[Future, Int] {  req @ given Req[A] => // error    

Req.async[Future, Int] {  case req @ given Req[Int] => // compiles but very tedious

   val r = summon[Req[A]]
   assert(r eq req)
    ???
  }
  
  
}

Expectation

This should compile:

Req.async[Future, Int] {  req : given Req[A] => 
   val r = summon[Req[A]]
   assert(r eq req)
    ???
}

This is probably a stretch given req's type is not ascribed:

Req.async[Future, Int] {  given req => 
   val r = summon[Req[A]]
   assert(r eq req)
    ???
}

But this looks like it should be possible:

Req.async[Future, Int] { req : given Req[A] => 
   val r = summon[Req[A]]
   assert(r eq req)
    ???
}

Extra 1

Note that a version of this works in Scala 3 already:

@main def Test() = {
  
  
  class MyC[A]( implicit val x: Req[A]) {
    summon[Req[A]]
  }
  
  
  class MyD[A](using val x: Req[A]) { // ok
    summon[Req[A]]
  }
  
}

Extra 2

However this version is probably not consistency with Scala 3 given.

  class MyD[A](using val x: Req[A]) {  // compiles but why `using` keyword instead of `given`
    summon[Req[A]]
  }

using is used to query implicits but here it is used to define an implicit. A better and more consistency keyword here is given:

  class MyD[A](given val x: Req[A]) {  // doesn't compile
    summon[Req[A]]
  }

[odersky]

The recommended Scala 3 idiom for this would be to use implicit function types. You can write an implicit function lambda like this:

   req ?=> ...

but it's type is an implicit function not a regular one. Nevertheless, I believe that adding more ways of defining an impllicit closure would be confusing. So if you want to define an implicit closure with regular function type you have to do it the long way:

req =>
  given Req[A] = req
  ...

But like I said, it's usually better to use ?=> throughout.

[odersky]

Moving to discussions

[therealcisse]

I think there are two potentially separate issues here:

1 Inconsistent use of using to define a given as seen here:

class MyClass[A](using val x: Req[A]) {  // compiles but why `using` keyword instead of `given`
    summon[Req[A]]
  }

I feel like this is very important since it is an inconsistency. I don't know how much this feature is used though.

@odersky: Should I create a separate issue for this ?

2 Missing feature parity with Scala 2 in Scala 3 contextual abstractions

  Req.async[Future, Int] {  implicit req => // how in Scala 3 ?
    
   val r = summon[Req[A]]
   assert(r eq req)
    ???
  }
  
  

Pros:

1 Speed up death of Scala 2 implicits. This is heavily used in current Play framework Actions.
2 Context queries can replace this but only for new code and only when defined in the API by the library author.
3 Nice to have feature

Cons:

1 If context queries are adapted in some future of Scala, this feature will probably hardly be used.
2 It is already possible to do this using patterns even though tedious:

Req.async[Future, Int] {  case req @ given Req[Int] => // compiles but very tedious

   val r = summon[Req[A]]
   assert(r eq req)
    ???
  }

All in all, I think both these should be in Scala 3.

[nicolasstucki]

This should work

  Req.async[Future, Int] { req ?=> // in Scala 3 
    val r = summon[Req[A]]
    assert(r eq req)
    ???
  }

[Jasper-M]

@nicolasstucki It does not though:

1 |Req.async[Future, Int] { req ?=> // in Scala 3
  |                         ^
  |                         Found:    Response[Int]
  |                         Required: Req[Int] => Response[Int]
2 |    val r = summon[Req[Int]]
3 |    assert(r eq req)
4 |    ???

[bishabosha]

inline def implicitfn[T, U](inline f: T ?=> U): T => U = f(using _)

Req.async[Future, Int](implicitfn { req ?=>
  val r = summon[Req[Int]]
  assert(r eq req)
  ???
})

[eloots]

The shortest I've come up with is:

Req.async[Future, Int] { req => given req.type = req
    
   val r = summon[Req[A]]
   assert(r eq req)
    ???
  }

[nartamonov]

I also was surprised that both { using req => } nor { given req => } are not compiles so far with Scala 3.0.1. As well as { req ?=> }. It's common idiom when programming with libraries such as ZIO, cats-effect, monix and so on. For example:

ZIO.runtime[Blocking].toManaged_.flatMap { implicit rt =>
  // ... 
}

I think there should exist some more succinct way to support this feature rather than explicitly define given instance:

rt =>
  given zio.Runtime[Blocking] = rt
  // ...

[odersky]

Scala 3 strives to be simple and regular. There are two kinds of function types: plain and contextual, and one kind of function literal for each type. Most libraries that encourage the use of implicit x => ... will be better off once they switch to context functions. That would make things significantly simpler and more streamlined. In the meantime, implicit x => ... is still available.

[megri]

Scala 3 strives to be simple and regular. There are two kinds of function types: plain and contextual, and one kind of function literal for each type. Most libraries that encourage the use of implicit x => ... will be better off once they switch to context functions. That would make things significantly simpler and more streamlined. In the meantime, implicit x => ... is still available.

Perhaps this does indeed make it more regular for everyone else, but I can't understand the rationale.

Before given/using there was a regularity in that you could add implicit in front of something to make it implicit, and it worked everywhere. The intent when adding it at the use-site is clear. With context functions this possibility seems prohibited.

The type of a lambda parameter can in most instances be excluded as it is already well defined. If I now want to promote the parameter to a given it needs to be added back again due to how givens are declared. This, to me, feels if not irregular then at least redundant.

I was under the impression that implicits were going away in the long term so using implicit x => … feels like using a deprecated method.

[odersky]

Before given/using there was a regularity in that you could add implicit in front of something to make it implicit, and it worked everywhere.

No: An implicit parameter of a method meant that the parameter was passed implicitly at the use site. But an implicit in a closure still produces a regular function that has to take an explicit argument. That's a glaring irregularity. It was sort of forced on us, since people felt they needed the use case, and we did not have context functions yet. It was also less visible in Scala 2 since you could pass a regular explicit argument for an implicit parameter. But with Scala-3's using clauses that's no longer possible.

In summary, Scala 3 has a clear distinction between implicit and explicit, and is uniform for internal use and external API. This plays a crucial role in making implicits safer and more predictable. We will not complicate the syntax and muddle the waters by introducing cases that blur the distinction again.

I was under the impression that implicits were going away in the long term so using implicit x => … feels like using a deprecated method.

Implicits will go away over time. Over the same timeframe libraries will hopefully migrate. Then you will be able to write

Req.async[Future, Int] {
  ...
}

which beats all the alternatives discussed so far by a huge margin.