-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crates should allow private impl of external traits for external structs #13721
Comments
Ran in to another use-case for #13009 that would be alleviated by allowing private impls: I'm trying to test an iterator that returns |
For the latter, you could map to a byte vector (either As for your struct, here's a wacky idea. We could extend #[deriving(Show)]
struct MyStruct {
x: int
#[deriving_show="p.display()"]
p: Path
y: int
} I don't know if this really is a great idea, but it's probably easier than coming up with some way to privately implement a trait for an external type. |
I did something similar in my testing by wrapping my results in a struct with a The private implementations of impls though are still a very useful feature. Go leans fairly heavily on its ability to define ad-hoc local implementations of interfaces in a module. |
@alanfalloon As I understand it, to implement an interface on an existing type in Go you need to actually produce a newtype and implement the interface on that. That's precisely what struct ShowablePath(Path);
impl Show for ShowablePath {
// ...
} The downside is you need to explicitly unwrap |
I'm very much in favor of this as well. It should be possible to extend existing types without having to wrap them in a unit struct. |
yes please! 👍 |
The possibilities opened by traits like this are part of why I got excited about Rust. 👍 |
+1 |
This should probably move over to rust-lang/rfcs. (cc @nick29581) |
This issue has been moved to the RFCs repo: rust-lang/rfcs#493 |
Support `rustc_has_incoherent_inherent_impls` Fixes us not resolving `<dyn Error>::downcast` now that `Error` moved to core, while that assoc function is declared in `alloc`.
Found while reading code: the comment was incorrect as it stops counting as soon as two elements are different. changelog: none
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:
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 implementingstd::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 ofShow
, you have made that decision for all programs everywhere. In my case, I had a large struct with numerousPath
elements that I wanted to print for debugging, but#[deriving(Show)]
won't work becausePath
has noShow
impl, and now I'm stuck either implementing it tediously from scratch, or switching tostr
for my path names.The perfect compromise would have been to allow my crate to define a private
Show
impl forPath
. There is precedent for this in other languages, go allows interfaces to implemented anywhere, for example.The text was updated successfully, but these errors were encountered: