Allow specifying what name to use for a field when using Encodable/Decodable.

[luqmana]

Sometimes you want to decode/encode a JSON object which has keys that are not valid rust identifiers and so you can't use Encodable/Decodable. This pull adds an attribute (#[encoded_name]) which lets you specify a string to use as the key to use for a given field.

extern crate serialize;
use serialize::json;

#[deriving(Encodable, Decodable)]
struct Data {
    metric: String,
    #[encoded_name = "metric-value"]
    value: int
}

fn main() {
    let input = r#"{"metric":"foo","metric-value":44}"#;

    // Decode the input JSON
    let data: Data = json::decode(input).unwrap();

    // Modify the input
    let data = Data {
        value: 32,
        ..data
    };

    // Encode it as JSON again
    let out: String = json::encode(&data);

    println!("data: {}", out);
    // data: {"metric":"foo","metric-value":32}
}

Note: this isn't JSON specific, anything that uses Encodable or Decodable will also be able to take advantage of this.

[emberian]

cc @erickt

[huonw]

I think we should have a reasonably structured plan for how we are going to make these sort of extensions to deriving, rather than just adding bits and pieces as they come up. That said, this seems mostly uncontroversial, although there's a small question about deriving(Show): should it be affected too?

[luqmana]

@huonw I don't think this should apply Show as I believe that should print the rust type as is. It's also a lot easier to handle this manually by implementing Show compared to implementing Encodable/Decodable.

[alexcrichton]

I agree with @huonw in that this seems desirable, but I would prefer a good story around customizing deriving in general before moving forward with this specific solution for encodable/decodable.

[lilyball]

I am very much interested in having a general story around customizing deriving. An old PR of mine (#14219) attempted to provide customizing of deriving(Default), and was closed for want of a general solution. I also have an issue #14268 around deriving in general wanting to ignore marker fields for most derivations (e.g. Show), which also would benefit from a general solution.

[jdm]

cc me

[alexcrichton]

ping @luqmana, we talked about this offline, any updates on this?

[alexcrichton]

Closing due to inactivity, but feel free to reopen with the modifications that we talked about!

If I recall correctly, the main concern was choosing a syntax here which was extensible for theoretically all deriving modes.