Over at Revisit Orphan Rules, the following was said:
Addendum: pub impl
If I was desigining this from scratch, I would say that the syntax which aligns best with the language would be to require implementations to be pub if an external module wanted to use them. So, for example, if you just had one crate A and wrote impl T for S then within crate A it would be able to use trait T, but if some other crate B imported S from A the implementation would not also be imported. If, on the other hand, crate A had pub impl T for S then B could import trait T with some syntax like use impl T for S from A. This seems to fit best with the rest of the language’s pub features, but it would be a breaking change and makes types more complicated. I’d rather not let this pub aspect hold up the solutions discussed above.
Maybe I missed it but I didn’t see this discussed in that thread and thought it might be worth it on its own.
My motivation for pub impl (in a future edition?) is that sometimes, it is convenient to provide a trait implementation for your own crate but you don’t want it to be a part of your public API. Examples:
-
From implementations for your Error type. If you migrate from one crate to another for your implementation (like glob to globwalk), you’d end up dropping a From and adding a different From implementation. These From implementations only exist to make it easier for your to use ?.
- In some cases, I’ve wanted to use
Serialize on a type that I don’t want to support serde on for the sake of a cheap but good looking Debug or Display
