circe-1.0.md

Circe 1.0 planning

Big-picture questions

• When do we release 1.0?
  • After Cats 1.0
  • After circe-algebra?
• How long do we support 1.0?
• How soon do we start 2.0?

Issues or PR with open questions

Fix the whole error situation

See #306.

• Should we provide more guidance about what the string(s) mean(s)?
• Should DecodingFailure#toString print a more human-friendly representation of the path?
• Should the failure include a representation of the path instead of the history (e.g. List(DownAt(2)) instead of List(MoveRight, MoveRight, DownArray))?

Reconsider number, object, and array representations and subtyping

See #697.

• Should JsonNumber and JsonObject extend Json?
• Should we have a JsonArray?
• Should we switch to reworked JsonNumber?
• Should we switch to reworked JsonObject?

Reconsider "folders"

See #656.

• Should we add an Folder1?
• Should we add a ReprFolder?

Add Printer abstraction

See #547.

• What does configuration look like?
• Do we want to support arbitrary writing directly to Appendable values?

Think about equality for Json

See #797.

• Should we add a "canonical" equality comparison?
• Should == ignore order?

Add java.time codecs to core for 2.12

See #754.

• Should we do it at all?
• What to do about Scala.js?
• Should we set up the build to get rid of the duplication?

Think about algebras

See #228.

• Should this happen in 1.0 or 2.0?
• What non-JSON operations should be supported (e.g. ReadTimestamp, ReadBinary, ReadUUID)?
• What happens to the cursor types?
• What should the encoding side look like?

Make builds reproducible

See #791.

• Should we hash the synthetic names to avoid collisions?
• Tests (this could be tricky).

Fix generic derivation for type tags

See #784, #688, etc.

Low-ish hanging fruit

Update Monocle

In circe-optics we're currently on 1.4.0 instead of 1.5.0-cats-M2. The switch should be straightforward but isn't entirely trivial, since we'll want to tear a bunch of Scalaz conversion stuff out.

Fix Decoder.state for optional fields

See #708. This is an annoying bug that's easy to work around, and is likely to be easy to fix, but it's in a less-used part of the API and I've not had time to address it.

Add a semi-automatic codec derivation method

See #133, but also the discussion here. The idea is that while we might not want a Codec type class, a semiauto.deriveCodec method returning a Decoder[A] with ObjectEncoder[A] might be useful.

Add a DownObject operation

Sometimes you're in a situation where you expect a single field in your object and don't care about the key. This is inconvenient, and it seems reasonable to have a DownObject operation that would do roughly the same thing as DownArray.