json now defaults Option<_> to None.

[treeman]

Closes #12794.

[lilyball]

This is not going to work right if I have a type named Option that is not std::option::Option.

Similarly, it presumably will not work right if I rename Option, using either use std::option::Option as Foo or type Foo = std::option::Option<int>.

[treeman]

Good point, I totally missed that.

[lilyball]

I feel like the right approach here really is to be able to provide a default value to use if the field isn't present. This is just another instance of the need to be able to customize deriving.

[alexcrichton]

Note that it is currently possible for decoders to emulate this behavior today, as it's what toml-rs does (and used quite extensively in cargo).

[treeman]

I agree @kballard, we need default values.

Thanks @alexcrichton, will take a peek.

[treeman]

Reworked the Option handling and now defaults to None for json only.

#17089 may enable us to specify default arguments, something like:

#[deriving(Decodable)]
struct Data {
    #[default = None]
    x: Option<uint>,
}

I still think it's more ergonomic to have Option default to None, at least in the json case.