Serializer and Deserializer should be pure interface

[lcy03406]

For now the Serializer and Deserializer traits contain many functions, but many of them have default implementations. A problem is, the default implementations make too many assumption about the serializing protocol, probably based on json. Though them may be convenient for implementing a json serializer, or other text protocols, but most of them do not suit for a binary protocol. The point is, Serializer and Deserializer are so big, that when implementing a concrete serializer/deserializer it is quite possible to accidentally miss some functions. So it is better to remove the default implementations, and make the Serializer and Deserializer traits a 'checklist', the compiler can help checking the implemention. In addition, the current default implementations can be moved to some JsonlikeSerializer or CommonTextSerializer sub-traits.

[oli-obk]

I agree. This "magic" has caused me some headache debugging, so I ended up replacing all of them manually.

[JohnHeitmann]

+1. I think magic layers are more appropriate for Deserialize/Serialize sugar, which are types that many serde users need to interact with. The -er types are relatively rarely implemented, and harder for an author to get complete ambient test coverage of via their own client code, so sacrificing sugar for correctness feels appropriate.

[erickt]

I can get behind this. One downside though with making this always pure is that any new hint we add would trigger a major release, or we just add a default implementation for that method. Would everyone be okay with this?

[jwilm]

@erickt adding a default implementation when adding a hint seems preferable to a major release. It's entirely backwards compatible this way, and formats which need the hinting can start using it immediately. Since this is all about getting rid of default impls, issues should be added to remove the default impl come the next major version.