[halotukozak]

ImplicitOptArg is like OptArg, but also accept implicit parameters (useful for DI or context parameters)

Example usage:

  class ClientSession

  val NoSession = ImplicitOptArg.Empty[ClientSession]

  class TransactionManager {
    def execute(transaction: ClientSession => Unit): Unit = ???
  }

  val transactionManager = new TransactionManager

  def doSomething(implicit session: ImplicitOptArg[ClientSession]): Unit = ???

  doSomething(using NoSession) // explicitly passing NoSession

  transactionManager.execute { implicit session =>
    doSomething // implicit session is passed
  }

[halotukozak]

@ddworak can we either proceed or close this PR?

[ddworak]

Thank you for proposing this idea. I don't think we should encourage implicit parameters with default values, especially when combined with optionality. OptArgs are often used in contexts where explicitness is highly desired (e.g. configuration, application bootstrap).

[halotukozak]

Thank you for proposing this idea. I don't think we should encourage implicit parameters with default values, especially when combined with optionality. OptArgs are often used in contexts where explicitness is highly desired (e.g. configuration, application bootstrap).

we do not encourage implicit parameters with default values. The default ones still must be passed explicitly (how it's already done internally with MaybeClientSession in DHCP and CAE with UserContext).
But I see, this mechanism could be abused