Conveniences that could be added to DBIO

[nafg]

• [x] DBIO.unit: DBIO[Unit]
• [x] DBIO.traverse[A, B, C[x] <: Iterable[x]](C[A])(A => DBIO[B]): DBIO[C[B]]
• [ ] DBIO.defer[A](=>A): DBIO[A]
• [x] [A] DBIO[A]#void: DBIO[Unit] (or another name)

[iRevive]

• [x] [A] DBIO[A]#as(A): DBIO[A] could be useful to: a shortcut for .map(_ => a).

[iRevive]

DBIO.defer[A](=>A): DBIO[A]

cats-effect IO has these meanings for delay / defer:

def delay[A](thunk: => A): IO[A] = ???
def defer[A](thunk: => IO[A]): IO[A] = delay(thunk).flatten

ZIO has defer only for the Config:

def defer[A](config: => Config[A]): Config[A]

Following this logic, the signature of the defer should be:

object DBIO {
  def defer[A](a: => DBIO[A]): DBIO[A]
}

In terms of the side-effect suspension, ZIO has:

def attempt[A](code: => A)(implicit trace: Trace): Task[A]
def succeed[A](a: => A)(implicit trace: Trace): ZIO[Any, Nothing, A]

---

Do you think we should consider other names for the [A](=>A): DBIO[A] signature?

• apply
• delay
• attempt

Since the DBIO API is similar to Future, DBIO.apply may fit. But I don't have a strong opinion, to be honest.

[nafg]

Not sure. Another options is .successfulLazy or something in that direction.

delay and attempt are good. Not sure about apply. In the case of Future, just opening up a block and marking it asynchronous is a basic way to use Future. Constructing a lazy DBIO is much more arcane, so I don't know if it deserves apply.

[mwisnicki]

Can flatMap be used to implement defer safely?

def defer[A](a: => DBIO[A]): DBIO[A] = DBIO.successful(()).flatMap(_ => a)(sameThreadExecutionContext)

[nafg]

Can flatMap be used to implement defer safely?

def defer[A](a: => DBIO[A]): DBIO[A] = DBIO.successful(()).flatMap(_ => a)(sameThreadExecutionContext)

I think so, I've done that in my own codebase