typelevel / typelevel/cats-effect

Add different effect init for `Random`/`SecureRandom`

Open
#4,410 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Scala
Stars
2.2k
Forks
576
Avg merge
2d 11h
Merged PRs (30d)
18

Description

I would like to be able to initialize Random in a different effect, as it's in Ref and Deffered (def in[F, G, A]). Motivation:

  • I can't use transformer implicits, because I want to initialize Random, for example, in ConnectionIO (type from Doobie, which has implementation of Sync for ConnectionIO).
  • I don't want to use mapK because it would be incorrect and expensive for implementation (ex: provided by lib mapK for ConnectionIO uses a Dispatcher that runs the logic, which adds additional costs for lift and unlift from IO)

Below is a sample code for Ref, I would like to be able to do exactly the same for Random and SecureRandom.

  import cats.FlatMap
  import cats.effect.std.Console
  import cats.effect.{Ref, Sync}
  import cats.syntax.all.*

  class Foo[F[_]: FlatMap: Console](ref: Ref[F, Int]) {
    def print: F[Unit] = ref.get.flatMap(Console[F].println)
  }

  def foo[I[_]: Sync, F[_]: Sync: Console]: I[Foo[F]] =
    for {
      ref <- Ref.in[I, F, Int](0)
      /// Init some classes in F
    } yield new Foo(ref)

Proposal:

I looked at current implementation javaSecuritySecureRandom, and it can be divided into 2 effects. So, new method will have signature like this:

// Proposal - add new method
def javaSecuritySecureRandomIn[I[_]: Sync, F[_]: Sync](n: Int): I[SecureRandom[F]]

// Current impl
def javaSecuritySecureRandom[F[_]: Sync](n: Int): F[SecureRandom[F]]

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the current javaSecuritySecureRandom implementation and compare its effect initialization with Ref.in and the proposed javaSecuritySecureRandomIn signature. Done means providing equivalent separate I and F initialization for Random and SecureRandom without relying on mapK, with the API and implementation behavior agreed.

Written by the indexing model from the issue text.

Assessment

Tech stack
scala
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.