Support for field renaming to workaround eg. OCaml keywords.

[mefyl]

AFAICT, there is currently no way to create a JSON object with a field name that collides with an OCaml keyword - for instance one cannot have a type key, since this is not valid OCaml:

let _ = [%ezjsonm { type = "whatever" }]

Two ideas come to mind, which I'm happy to implement myself if I get a greenlight. Other ideas welcome, of course.

Automatic field renaming

Automatically trim underscores at the start of identifiers, so one can write

let _ = [%ezjsonm { _type = "whatever" }]

Js_of_ocaml does this, for instance. Trimming the underscore at the beginning instead of the end unlocks capitalized fields, which are not valid record field names in OCaml.

Pros: Fast and easy.
Cons: Harder to have JSON field names that actually end with underscores (although those are rather rare), not backward compatible.

An additional idea would be to do this iif the word before _ actually is a keyword.

Manual field renaming with an annotation

For instance:

let _ = [%ezjsonm { type_ = "whatever" [@as "type"]  }];

Pros: Backward compatible, handles every case.
Cons: Verbose.

[NathanReb]

Thanks for reporting this and for taking the time to look into the solutions and there pros and cons! Both seem great!

Indeed the prefix thing would be preferable to the attribute solution. It's both easier to use and to implement as the attribute would be attached to the expression bound to the field (nothing impossible to deal with but slightly more tedious).

As you point out there's a risk that it prevents users from writing fields that starts with an underscore. To solve that, what would you think about the following rewriting rule: If the field name starts with an underscore, just remove it unconditionally and leave the rest unchanged.

That way, you should still be able to write JSON field that starts with _ by simply adding an extra leading _, e.g. __secret_field would be rewritten to _secret_field.

The attribute being backward compatible is good indeed but I don't think it would hurt to release a new major version. Actually since we're adding breaking changes, we could also use this occasion to rename the package to ppx_json since it's not yojson specific anymore thanks to your previous contribution!

I think a PR for the rewriting would be welcome as it is bound to get in at some point anyway. I might implement the attribute based solution as well and cut a release with it before to allow for a smooth transition.