Map[Boolean, T] fails to encode with 'could not find Lazy implicit value of type DerivedAsObjectEncoder[Foo]'

Build Details

Circe : 0.14.0-M1 Scala : 2.12.10

Problem

If there is a case class, with an element that is a Map where key is Boolean, the encoding fails with an unclear error message

could not find Lazy implicit value of type io.circe.generic.encoding.DerivedAsObjectEncoder[Foo]
not enough arguments for method deriveEncoder: (implicit encode: shapeless.Lazy[io.circe.generic.encoding.DerivedAsObjectEncoder[Foo]])io.circe.Encoder.AsObject[Foo].
Unspecified value parameter encode.

Code

import io.circe.Encoder
import io.circe.syntax._
import io.circe.generic.semiauto.deriveEncoder

case class Foo(boolKeyMap: Map[Boolean, String])

object Foo {
  implicit val encFoo: Encoder[Foo] = deriveEncoder[Foo]
}
println(
  Foo(boolKeyMap = Map(true -> "str")).asJson.spaces2
)

Scastie link

https://scastie.scala-lang.org/0PSRfw5JRASQGBEcHyWAhA

Question

I’m wondering if this is intended behavior and if so, is there scope of improving the error message.

[zarthross]

@praateekmahajan I think the problem with us implementing a Boolean KeyEncoder or KeyDecoder is going to be choosing a canonical representation. For all the key encoder/decoders so far there is a very clear representation to choose, including URI and UUID. But for boolean, do we go with TRUE, true, True, or 1? We cannot choose all of them, because you could have multiple of those keys within a Json Objects. I think the safest thing for us, as a library would be to let any user who needs a KeyEncoder[Boolean] to implement the specific one they want.

For instance, you could add this next to your encoder and solve your problem, with a bonus decoder too: (scastie link)

  implicit val encBoolKey: KeyEncoder[Boolean] = KeyEncoder[String].contramap(_.toString)
  implicit val decBoolKey: KeyDecoder[Boolean] = KeyDecoder.instance {
    case "true" => Option(true)
    case "false" => Option(false)
    case _ => None
  }

[praateekmahajan]

Thank you for engaging in the conversation, I agree it’s not common and could be better defined in a case class with two values.

For my understanding, would there be a reason to not add the Boolean encoder to KeyEncoder? Not common is a good reason that it isn’t already there but wondering if it’s a good enough reason to not include it further (assuming the time to create and merge the PR is free)? I see URI in the KeyEncoder which makes me think that’s a further rarer key, yet possible key, similarly Boolean, rare key yet possible.