-
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
deriving(Eq) requires Eq for type parameter even when phantom #7671
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: