I currently have the following in my Gradle build file:

circeVersion = '0.11.1'

// ...

compile "io.circe:circe-core_%%:${circeVersion}"
compile "io.circe:circe-generic_%%:${circeVersion}"
compile "io.circe:circe-parser_%%:${circeVersion}"
compile "io.circe:circe-optics_%%:0.11.0"

because 0.11.1 is not released to Maven.

It would be nice if the version of the optics was always in line with the main Circe library.

Alternatively, if that's not feasible, a note about optics version being different should be provided in the optics documentation which currently simply says circeVersion.

This project has been unmaintained for a long time, especially since one of the crucial dependencies Monocle has been outdated, and its API changes rapidly in the new versions.
If needed, I'm willing to do the necessary work to keep the dependency up to date.

Although the main Circe project has (RC) releases for Scala 2.13.0, circe-optics doesn't. Would be nice to have one to try things out and migrate.

I see that Circe was updated to 0.12.0-M4 recently, but don't see a corresponding release for optics on that version: https://mvnrepository.com/artifact/io.circe/circe-optics

Am I missing something?

problem:
for given JSON { "foo": { "baz": 1 } } and two cursor
json.hcursor.downField("foo").downField("bar").as[Option[String]]
root.foo.bar.as[Option[String]].getOption(json)

first one got Right(None) indicated parse success but got no value as expected.
but Optics got just None, which can only be understood as parse failed i guess.

is this behavior intended? and if i want first behavior but still use JsonPath's convenient syntax is there any way?
thanks

Problem

Consider a JSON:

{"foo": {"bar": {"goo": {"car": { /* some complex structure inside */ }}}}}

We need to parse and decode the car object into some model:

class Car( /* some accordingly complex structure inside */ )

We don't care about writing this model back to JSON so we only have implemented a Decoder for it:

implicit val carDecoder: Decoder[Car] = { cursor => ??? /* some custom decoder */ }

Now we're attempting to create a JSON path based optic to access it:

JsonPath.root.foo.bar.goo.car.as[Car] // does not compile: could not find implicit value for parameter encode: io.circe.Encoder[Car]

This line fails to compile since the as method requires both Decoder and Encoder (which makes it different from Json#as for example).

Having an Encoder instance could come in handy if we wanted to set/modify the source JSON with some new or update Car instance. But if we don't need to do it (I bet it is 90% or even 99% cases of what JSON paths are created for), then the Encoder instance is not used somehow and just does not allow us to read our model in this way if the model does not have an encoder.

The same can be applied to JsonTraversalPath and JsonFoldPath.
But the latter case is a bit ridiculous, because JsonFoldPath creates a Fold instance, but still requires an Encoder.
The Fold optic cannot be used for "set" or "modify" operations so that encoder comes completely redundant.

Would be nice to match the main circe project with Scala3 support in the optics.

The problem:
Given the following json:

{
  "data:0": [0, 122, [0, [111]]]
}

I wanna get a number 111 which in scala code looks like this

val lens = root.selectDynamic("data:0")(2)(1)(0).int

It would be useful have some method (e.g. path) which takes path (HList or list of strings) and return an element on given path. JS library Rambda already had them
https://ramdajs.com/docs/#path
https://ramdajs.com/docs/#lensPath

So this is rather a question or discussion about whether those functions should be added or not?
Maybe there is an idiomatic Scala solution I don't know about?
/cc: @julien-truffaut @travisbrown