use serde

[BurntSushi]

I should start using serde for the automatic serialization component of this crate.

I don't think this means removing support for rustc-serialize just yet though.

[Hoverbear]

You could use cargo features to facilitate people being able to choose.

[lisael]

Correct me if I'm wrong, but I guess Docopt serializations will ever happen once at the very start of the process.

Is gaining 2ms important enough to add dependencies, complexify the buid process (and code), and create two very different builds (nightly and beta/stable) with two different classes of bugs and maintenance burden ?

[BurntSushi]

I don't feel an urgency to use serde yet personally, but I do imagine that rustc-serialize will go away at some point in the future, and there will probably be a transitory period where we support both.

[nixpulvis]

Issues like rust-lang-deprecated/rustc-serialize#128 make me really nervous relying on this.

[BurntSushi]

@nixpulvis That's not a bug in the serialization infrastructure. It's probably a bug in the JSON specific code. It doesn't affect Docopt. Consider this program:

extern crate docopt;
extern crate rustc_serialize;

use docopt::Docopt;

const USAGE: &'static str = "
Usage: program [-x ARG -y ARG]

Options:
    -x ARG
    -y ARG
";

#[derive(Debug, RustcDecodable)]
struct Args {
    flag_x: f64,
    flag_y: f64,
}

fn main() {
    let args: Args = Docopt::new(USAGE)
                            .and_then(|d| d.decode())
                            .unwrap_or_else(|e| e.exit());
    println!("{:?}", args);
}

If you try to invoke it without either -x or -y (even though they are optional as far as Docopt is concerned), you'll get a decoding error:

[andrew@Liger docopt-128] ./target/debug/docopt-128 
Could not decode '' to f64 for '-x'.
[andrew@Liger docopt-128] ./target/debug/docopt-128 -x 1.2
Could not decode '' to f64 for '-y'.
[andrew@Liger docopt-128] ./target/debug/docopt-128 -x 1.2 -y 1.3
Args { flag_x: 1.2, flag_y: 1.3 }

(This means that you must use Option<f64> to make such fields truly optional.)

[SuperFluffy]

I arrived here because I was also looking into optional settings with f64 arguments. Is this Could not decode '' to f64 for '--flag'. error something that should be reported to rustc_serialize or potentially later to serde?

[BurntSushi]

@SuperFluffy Could you please clarify? What is wrong with using Option<f64> for an optional argument or flag?

[SuperFluffy]

It is only necessary for f64 but not for, say, u64. In fact, I have the following struct where both flags are optional, just that I need to wrap the f64 in an Option<>, which is not necessary for u64.

struct Args {
    flag_foo: Option<f64>,
    flag_bar: u64,
}

I'd prefer if there was some consistency in this by either not having to wrap the f64 or having to wrap the other primitives as well.

[BurntSushi]

@SuperFluffy OK, that does indeed look like a bug, but it's really not related to adding serde support to docopt, so I filed a new issue: #142

[ajdlinux]

Now that the Macros 1.1 API that serde needs in order to avoid the awful codegen hacks is getting closer to being stabilised, is this something that can be looked at during the next few rustc release cycles?

I'm currently planning to migrate one of my projects to serde as it's significantly more flexible and alas docopt is the only thing that will stop me from removing rustc_serialize altogether...

[BurntSushi]

It seems like serde and rustc-serialize can happily coexist, so I don't think this is going to be high on my priority list. With that said, I would like to eventually move docopt and csv to using serde. I just don't know when it's going to happen.

[ajdlinux]

Indeed they can - the fewer dependencies the better of course, but understandable if this takes some time :)