-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
case object doesn't encode correctly #1114
Comments
Hi, @DesZhang! Thanks for your feedback and support! I would say that The root cause of issue that types are different for I've pasted your code to the module tests and got the following type hint for Possible other workarounds to help scalac derive a proper type are using an explicit type when creating value or writing it : writeToString(Error[ErrCode](errType1, "msg"))
writeToString[Error[ErrCode]](err) Yet another solution could be removing (or commenting out) of a redundant codec for //given JsonValueCodec[errType1.type] = JsonCodecMaker.make Then compiler will say that |
@plokhotnyuk Thank you for quick response, the last part is exactly what I was trying to deal with. Do I have to widen the type explicitly every time so the compiler could use and I'm still confused why value of |
The best option would be using of non-generic final case class Error(code: ErrCode, msg: String)
given codec: JsonValueCodec[Error] = JsonCodecMaker.make(CodecMakerConfig.withDiscriminatorFieldName(None))
sealed trait ErrCode
@named("error type 1")
case object errType1 extends ErrCode
@named("error type 2")
case object errType2 extends ErrCode
val err = Error(errType1, "msg")
val gErr: Error = err
// {"code":"error type 1","msg":"msg"}
println(writeToString(err))
// {"code":"error type 1","msg":"msg"}
println(writeToString(gErr)) |
@plokhotnyuk thank you |
@DesZhang I have no confidence if proposed solutions were acceptable for you. Yes, for your version of code snippet widening is required because the compiler tends to derive the narrowest type. The codec generated by Sometime users report minimized code for their issue without description of the context, so my willing to get the simplest solution could be unacceptable or hard to grasp. Have you migrated from Scala 2 or your code was initially created for other json library? As example, if you migrate your code from circe or upickle codecs replacing them by jsoniter-scala codecs step by step, than it could be a long journey. The ideal approach would be to start from tests for top-level messages and derive only required jsoniter-scala codecs. |
@plokhotnyuk thank you and sorry for late response. I used type parameter to make different types of I've started a new project with sealed trait Error[+E <: Code] {
val code: E
val msg: String
}
@named("basic")
final case class BasicError[E <: Code](
code: E,
msg: String
) extends Error[E]
@named("line")
final case class LineError[E <: Code](
code: E,
ln: LineNumber,
msg: String
) extends Error[E]
sealed trait Code
@named("0001")
case object notFound extends Code
type NotFound = Error[notFound.type]
@named("0002")
case object incomplete extends Code
type Incomplete = Error[incomplete.type]
// compiler warning: the type test for BasicError[Code] cannot be checked at runtime because
// its type arguments can't be determined from Error[Code]
given JsonValueCodec[Error[Code]] = JsonCodecMaker.make(
CodecMakerConfig
.withDiscriminatorFieldName(Some("tpe"))
.withRequireDiscriminatorFirst(true)
)
The compiler(scala 3.4.0) complains about type test problem caused by type erasure, my guess is that pattern match happened somewhere in code generated by jsoniter-scala macro, since Beside the question above, another strange thing is, I have almost the same error coding pattern in another project, by "almost" I mean they only have different class/trait names, and I got no warning at all, both projects have the same versions of |
@DesZhang Thanks for your feedback! Please peek the latest release with a fix for unwanted warning: https://github.com/plokhotnyuk/jsoniter-scala/releases/tag/v2.28.4 |
@plokhotnyuk wow,that was lightning fast, I'll try and report back asap |
@plokhotnyuk 2.28.4 works as expected, thanks. |
Recently I upgrade to 2.27.7 in my scala 3 project, the minimal example is:
obviously
json1
is incorrect.BTW: the library is amazing, thank you.
The text was updated successfully, but these errors were encountered: