-
Notifications
You must be signed in to change notification settings - Fork 13.4k
deriving(Eq) requires Eq for type parameter even when phantom #7671
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
This issue is more general than just that deriving Eq requires an Eq bound. As well, deriving Clone requires a Clone bound on all template type parameters. |
This could possibly be controlled by, e.g., |
The |
I think Haskell's deriving is built into the type system more strongly than Rust's, which is just a standard syntax extension (it runs on exactly the same code as |
triage: no change. |
This hit me today with: #[derive(Debug)] struct Foo;
struct Bar;
#[derive(Debug)] struct Baz<T>(u64);
fn main() {
println!("{:?}", Baz::<Foo>(10));
println!("{:?}", Baz::<Bar>(10)); // Does not compile.
} |
Now that Rust has struct NoClone;
struct Foo<A, B, C> {
a: u8,
b: Option<B>,
c: C
}
// CURRENT, wrong way to implement clone in deriving
impl<A: Clone, B: Clone, C: Clone> Clone for Foo<A, B, C> {
fn clone(&self) -> Self {
Foo {
a: Clone::clone(&self.a),
b: Clone::clone(&self.b),
c: Clone::clone(&self.c),
}
}
}
// NEW, Right way to implement clone in deriving
impl<A, B, C> Clone for Foo<A, B, C> where Option<B>: Clone,
C: Clone {
fn clone(&self) -> Self {
Foo {
a: Clone::clone(&self.a),
b: Clone::clone(&self.b),
c: Clone::clone(&self.c),
}
}
}
fn main() {
let t: Foo<NoClone, String, &'static str> = Foo { a: 0, b: None, c: "foo" };
let _ = t.clone();
} This should be implementable on a purely syntactic level. |
The above is implemented in #21237, but unfortunately it seems to have a problem: what if a type inside the struct is private? You can't put a bound on a private type on the trait impl, because the user of your crate (say) doesn't know what impls exist for the private type :( edit: hm, that PR was updated since I last looked at it - maybe it's a bit different now? |
…ical Switch to using correct fixme link Issue rust-lang/rust#7671 was closed, the new issue is rust-lang/rust#26925
…ednet Downgrade many_single_char_names to pedantic As suggested by `@flip1995` in rust-lang/rust-clippy#7666 (comment), by today's standards this lint would be considered `pedantic`. This is one of the most widely suppressed Clippy lints on crates.io according to https://github.com/dtolnay/noisy-clippy. In my opinion this lint is just too domain specific for Clippy to have reliable visibility into. Sure there are some cases where the author is just being lazy and could use a kick in the butt, but we're still left with an enormous number of suppressions where single chars are the most appropriate name. For example in the context of colors, a function using `h`, `s`, `l`, `r`, `g`, `b` is 100% sensible and spelling all those out is silly, but it's past the default lint threshold. --- changelog: Moved [`many_single_char_names`] to `pedantic`
We can't use Rust's default deriving mechanism, until rust-lang/rust#26925 and rust-lang/rust#7671 are fixed. But fortunately, there's a crate for that.
We can't use Rust's default deriving mechanism, until rust-lang/rust#26925 and rust-lang/rust#7671 are fixed. But fortunately, there's a crate for that.
We can't use Rust's default deriving mechanism, until rust-lang/rust#26925 and rust-lang/rust#7671 are fixed. But fortunately, there's a crate for that.
Code:
Result:
The text was updated successfully, but these errors were encountered: