Why `json.key` for records but `json.name` for variants?

[jchavarri]

Confused about this choice. There are already quite a lot of PPX attributes, and this case uses different names for different types for the same functionality. Could they both be called json.name?

Or to reduce cognitive impedance even more, use json.as which is very similar to mel.as.

[andreypopp]

this was done to align with ppx_yojson_conv and ppx_jsonschema_deriving

[jchavarri]

But they still require to remember two attributes for the same thing. Besides, they are named name and key, not json.name and json.key. So no reuse is possible (if I want to use both melange-json and one of these ppxs, i'd need to add [@name "foo"][@json.name "foo"]).

Would you be open to support json.as in addition to the existing fields?

[andreypopp]

They can specify attributes without the namespace, e.g. @key will work both with json (both of them) and jsonschema deriving plugins.

[tatchi]

Today I used

type application = {
  type_ : Aa_fe.Application.Type.t; [@json.name "type"]
}

And was surprised it didn't work until I realized that I should use json.key instead. It'd be nice to at least give an error in this case