@jwcarvana Thanks for reporting!

I've just added a missing check for default value memorization in jsoniter-scala and it passes for both Scala 2 and Scala 3 versions.

Probably similar macro implementations could be used to fix the issue in zio-json, if it is not designed intentionally to support only constant values for defaults.

/bounty $100

💎 $100 bounty • ZIO

Steps to solve:

1. Start working: Comment /attempt #1055 with your implementation plan
2. Submit work: Create a pull request including /claim #1055 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to zio/zio-json!

Add a bounty • Share on socials

/attempt #1055

Side note: default parameters are not working in Scala 3 at all, unless users add the -Yretain-trees scalac option.

Given the following case class:

final case class RandomClass(
  str: String,
  uuid: UUID = UUID.randomUUID
)

And the following code in zio.json.macros.DeriveJsonDecoder.join:

def getDefaults: Array[Option[Any]] = {
  println(s"Random id: ${UUID.randomUUID().toString}")
  println(ctx.parameters.map(_.default).toArray.mkString("Array(", ", ", ")"))
  ctx.parameters.map(_.default).toArray
}

The first logged id is different every time a string is decoded into a RandomClass, while the second id is the same. E.g. this issue comes from Magnolia. It can be fixed in several ways:

1. A PR into Magnolia. I'm not sure that this fits with their design and would likely involve a change breaking binary compat.
2. A change in zio-json involving an annotation such as fieldDefaultValue, like there is in zio-schema. Currently all annotations in zio-json relate to field names, not to values. Is this by design?
3. No code change - add documentation explaining how to work with default parameters generally (including how to deal with defaults in Scala 3), as well as a workaround if users want to have dynamic default values.

I would tend towards 3 - serialization with random generators isn't referentially transparent and I would lean towards keeping the two separate and doing random generation as part of an effect, serializing the case class with a default null value, and then copying the randomly generated value over. If there are performance considerations, then the following should suffice:

final case class RandomClass(
  str: String,
  @jsonField("id")
  private val initialId: UUID = null
) {
  val id: UUID = if (initialId == null) {
    UUID.randomUUID()
  } else {
    initialId
  }
}

@jdegoes , any preferences here?

@Andrapyre: Reminder that in 7 days the bounty will become up for grabs, so please submit a pull request before then 🙏

The bounty is up for grabs! Everyone is welcome to /attempt #1055 🙌

💡 @Andrapyre submitted a pull request that claims the bounty. You can visit your bounty board to reward.