Update to serde 0.9

[dtolnay]

Release notes: https://github.com/serde-rs/serde/releases/tag/v0.9.0

One thing we need to figure out is where to handle all the things that currently happen inside MapDeserializer::missing_field.

[RReverser]

Just FWIW, I've implemented own Serde 0.9 compatible deserializer with support for enums, collections of enums, and other features this deserializer lacked for me here https://github.com/RReverser/serde-xml-rs

[dtolnay]

This is amazing. @oli-obk how would you feel about handing ownership of serde_xml on crates.io over to @RReverser and abandoning this codebase? IIRC you were pretty pessimistic about the future of this crate (the words were something like "failed experiment").

[oli-obk]

(the words were something like "failed experiment").

yes. this repo would need a rewrite. It is unsalvageable.

I suggest to keep the tests though (or at least take them as a starting point, some of them should probably be broken in a better serializer, but all of them should be implementable)

[RReverser]

@oli-obk Sure, I can copy-paste your tests to my repo if that's okay with you.

[dtolnay]

Great. @RReverser up to you whether you would like to keep the repo under your account or take over this one. If you keep yours, please open issues corresponding to every open issue here, and leave a comment on our issues linking to yours. Then I will add you as an owner of serde_xml on crates.io and you can push your version.

[RReverser]

@dtolnay At the moment I'm seeing quite a bit failed tests from actual serde_xml, when I'll have time, I'd like to fix them before making any further decisions, but will be able to do that only on the next week.

[oli-obk]

Sure, I can copy-paste your tests to my repo if that's okay with you.

sgtm

At the moment I'm seeing quite a bit failed tests from actual serde_xml,

Always verify that they make sense and don't require complex dances in the deserializer impl. It can always be required that the user writes a complex type to satisfy weird xml structures, but you should not strife to support them by default from simple structures. That's one of the problems I've had in this repository.

[RReverser]

@oli-obk Sure. For example, tuple/unit failures are valid, and I'm working on improving their support, but I don't want, for example, to allow parsing primitives from <wrapper>primitive</wrapper>, as that's not really eligible for round-trip.

[indiv0]

@RReverser Would this then prohibit something like:

type Plaintext = String;

<plaintext>sometext</plaintext>
<plaintext/>

?

Because that's a use-case I need.

[RReverser]

@indiv0 Yes, because for Rust type is just a transparent alias - when you use it, it's not even a wrapper, but exactly as if you would write String there in the first place.

[indiv0]

@RReverser Alright. How would I go about handling that case then?

(Also I realize this is a bit off-topic for this issue. If you'd like, we could move this discussion to a serde_xml_rs issue)

[RReverser]

@indiv0 Sure, please do.

[RReverser]

@oli-obk @dtolnay Looks like I don't have much time to evolve serde-xml-rs as I don't do anything related to XML parsing which motivated me to create it in the first place.

At the same time, this original repo/crate is deprecated, so I thought if you still feel that it's worth it, we can move repo and/or rename crate as was originally suggested.

[oli-obk]

Yea we should do that. I can give you access rights to the serde-xml crate and then you can push your crate there as a 1.0 version.

[RReverser]

Sounds good. Should we move repo over as well?

[dtolnay]

I would leave the repo with you. I don't expect XML to become a flagship Serde format (especially if no longer actively developed) and the link from https://serde.rs should make it sufficiently discoverable.