No, this is not possible.

The problem with adding this as a feature is that it is not flexible; there is no single format JSON APIs use for serializing sum types.

Ok, no problems. I just used Yojson.Safe.json

I'm actually open to ideas in regards to this, I just don't know how/if it can be implemented without bloating the interface terribly.

Mmmh at least allowing [@name "name"] on record fields would be very helpful.
The field has name type, but it's an ocaml keyword so I can't create the field.

By the way, generally speaking, with ppx is it possible to enforce that attributes (such as ``[@name "name"]`) have to be used by a ppx module ?

https://github.com/whitequark/ppx_deriving_yojson#options

And to the second question, no. There's been discussion on schemas on mantis but those are vaporware.

Ohh thanks a lot !

I have to deal with similar json schemes, I usually handle this the following way:

1. I define functions adresse_of_yojson : json -> [>Ok of string | Error of string]andgeo_coord_of_yojson : json -> [> Ok of geo_coord | Error of string] and have to bind them in a monadic way, which – without cutting through monadic operators – boils down to

match adresse_of_yojson json  with
| `Ok(a) -> `Ok(Adresse(a))
| `Error(_) ->
  begin match geo_coord_of_yojson json with
  | `Ok(c) -> `Ok(GeoCoordinates(c))
  | `Error(_) as error -> error
end

It is not very easy to figure out a solution that will work with all popular APIs because they all have their pecularities. Maybe an acceptable solution would be the ability to specify for a specific field a family of deserialisers that would have to be tried sequentially deserailse the json structure.

I am not sure how this feature should be combined with variants – should they return Adresse(a) or just a ? In the former case the extension interface would be clean and lean, in the latter case, it would save red typing for the programmer.