Revisit Orphan Rules

[Ixrec]

@mboratko

Right now it’s relatively feasible to recommend crates to implement Serialize, Deserialize (even though, as my own experience shows, that recommendation doesn’t seem to be followed) but what happens when there’s a crate which implements a Loggable trait so that one can indicate how structs should be printed in a log? Sure, perhaps using Display or Debug would be fine, but maybe some other interface would be better (eg. saving the size of a struct in the log might be helpful, or one might want to pass parameters to the logging module which effects how all structs are saved). What about printing out Rust structs to HTML, general DOM interaction traits (once this hits WASM), or a WASMDebug trait which would benefit from a slightly different format than the console Debug ?

These are all examples of general traits, so perhaps the list of recommended traits just gets longer. What about implementing EsotericTraitA for SomeStruct , which only a couple of crates would benefit from? Sure, you can say “well, if only a couple crates benefit from it, it’s not a concern.” The point is that for one specific trait that might be the case, but then there’s EsotericTraitB and EsotericTraitC … one certainly can’t expect the author of SomeStruct (as well as any authors of nested structs that SomeStruct depends on) to keep all these implementations in their crate and up-to-date, nor can they expect the trait authors to be aware of all the structs that might possibly be used with their crates.

afaik, in every other language the list of traits/interfaces that everyone is expected to provide implementations for is basically the same as Rust: something to stringify the type for logs, something to serialize the type for persistent storage, and value type semantics like equality and ordering when applicable. For every other interface, the assumption was that you'll use inheritance/wrapper types if you really need it.

I think the only meaningful difference between Rust and Java/C# here is that Rust's Serialize trait is not part of the core language or standard library, which I suspect is one of the reasons this might feel like a much bigger problem than it did in those two languages: Java/C# never really had an interface in a 3rd party library that "everyone should implement".

But I don't think that automatically means Rust's list of 3rd party traits that everyone needs to implement is likely to grow in the future; I still think that serialization is special and it's unlikely we'll ever need to make such a recommendation for anything else.