Today on Gitter @julienrf asked the following question:
@travisbrown can you remind me why you decided to remove CodecJson?
And my response:
@julienrf Primarily because I think the role it plays in Argonaut is confusing. It can be handy for definitions, but you generally don't want to use it as a context bound anywhere except tests, since there aren't CodecJson instances for lots of things that have DecodeJson and EncodeJson instances…
@julienrf …and that's the case because you can't define e.g. CodecJson[String] in the CodecJson companion object, since then it wouldn't be found when you ask for DecodeJson[String].
@julienrf So you could either put all your CodecJson instances for these basic types in some object that you expect users to import (ugh), or have some kind of implicit that automatically combines DecodeJson and EncodeJson into a CodecJson (which was removed in Argonaut for reasons I don't exactly remember, although I can imagine how that might get messy), or do what Argonaut does and just provide CodecJson for convenient definitions and let users figure out why it's pretty much useless as a requirement.
None of those options are very nice, so at the beginning I decided to leave it out of circe entirely.
It's possible that it's possible to do it right (or at least dramatically better) with export-hook, and I'd definitely be open to that possibility.
My wishlist for a Codec type class in circe would look something like this:
- A
Codec[A] should be available (without any imports) for any A that has a Decoder and Encoder—i.e. if io.circe.Decoder[A] and io.circe.Encoder[A] compile, then io.circe.Codec[A] must compile as well.
- All tests should pass as currently written.
- If a type has a
Codec instance, then asking for a Decoder (or Encoder) for that type shouldn't require additional allocations.
- We shouldn't have to change the name of the
apply methods on Decoder or Encoder.
- It should be possible to define
Codec instances for standard library and circe types in the Codec companion object and have Encoder and Decoder instances available with no imports.
Only the first two are hard requirements, and the third and fourth are probably incompatible.
Today on Gitter @julienrf asked the following question:
And my response:
My wishlist for a
Codectype class in circe would look something like this:Codec[A]should be available (without any imports) for anyAthat has aDecoderandEncoder—i.e. ifio.circe.Decoder[A]andio.circe.Encoder[A]compile, thenio.circe.Codec[A]must compile as well.Codecinstance, then asking for aDecoder(orEncoder) for that type shouldn't require additional allocations.applymethods onDecoderorEncoder.Codecinstances for standard library and circe types in theCodeccompanion object and haveEncoderandDecoderinstances available with no imports.Only the first two are hard requirements, and the third and fourth are probably incompatible.