Crates should allow private impl of external traits for external structs

Issue by alanfalloon
Thursday Apr 24, 2014 at 02:31 GMT

For earlier discussion, see https://github.com/rust-lang/rust/issues/13721

This issue was labelled with: in the Rust repository

As you know, you can't provide an impl for a trait if neither the type nor the trait are defined in the current crate, you get:

error: cannot provide an extension implementation where both trait and type are not defined in this crate

For public implementations, this makes perfect sense, there are issues with collisions between implementations and sheer surprise. However, for a private implementation of the trait, this is a real hindrance.

Consider the case of std::path::Path not implementing std::fmt::Show. The rationale for closing #13009 is perfectly valid: we don't want people treating paths as strings. However, by refusing to add an implementation of Show, you have made that decision for all programs everywhere. In my case, I had a large struct with numerous Path elements that I wanted to print for debugging, but #[deriving(Show)] won't work because Path has no Show impl, and now I'm stuck either implementing it tediously from scratch, or switching to str for my path names.

The perfect compromise would have been to allow my crate to define a private Show impl for Path. There is precedent for this in other languages, go allows interfaces to implemented anywhere, for example.

Start with the earlier discussion in Rust issue #13721 and the reported coherence error about implementing an external trait for an external type. Review the existing 90-comment thread to identify the unresolved design constraints. Done would require a documented, accepted approach for private implementations rather than a narrowly scoped edit.