5 ms·

It's surprising up to the moment the compilation error tells you that all of the members have to implement derived trait. Nevertheless, it would be cool to be

by 0rzech 1y ago

It's surprising up to the moment the compilation error tells you that all of the members have to implement derived trait. Nevertheless, it would be cool to be able to add #[noderive(Trait)] or something to a field not to be included in automatic trait implementation. Especially that sometimes foreign types do not implement some traits and one has to implement lots of boilerplate just to ignore fields of those types. I know of Derivative crate [1], but it's yet another dependency in an increasingly NPM-like dependency tree of a modern Rust project. All in all, I resort to manual trait implementations when needed, just as GP. [1] https://crates.io/crates/derivative https://crates.io/crates/derivative

0rzech 1y ago
Apparently, Derivative is unmaintained [1], but there is Derive_more [2], Educe [3] and Derive-where [4], if anyone is interested. [1] https://rustsec.org/advisories/RUSTSEC-2024-0388.html https://rustsec.org/advisories/RUSTSEC-2024-0388.html [2] https://crates.io/crates/derive_more https://crates.io/crates/derive_more [3] https://crates.io/crates/educe https://crates.io/crates/educe [4] https://crates.io/crates/derive-where https://crates.io/crates/derive-where
josephg 1y ago
> It's surprising up to the moment the compilation error tells you … Unfortunately this problem only shows up when you’re combining derive with certain generic parameters for the first time. The first time I saw this, I thought the mistake was mine. It was so surprising and confusing that it took half an hour to figure out what the problem was. I thought it was a compiler bug for awhile and went to file it on the rust project - only to find lots of people had beat me to it. Aside from anything else, it’d be great if rust had better error messages when you run into this issue.
- duped 1y ago
  It took you 30 minutes to understand what "could not call Clone::clone because <type> does not satisfy Clone" means?The error message tells you exactly what the problem is and how to fix it. This is a pet peeve of mine so I'm sorry to be overly dismissive. There are bad error messages out there in the world that are impossible to parse, but this is not one of them. Trying to file a github issue before attempting to understand the error message is insane to me.
  - josephg 1y ago
    Yes it took me 30 minutes. The error message in this case is uncharacteristically bad. Or I found it particularly confusing because of quirks in my understanding of rust’s type system. Take a look. Do you think this quirk of derive is obvious from the error message alone? Would you have figured it out, in the context of a much more complex program with dozens of other changes that may or may not have been related? https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f4c0d2a1e93fc80487c8708782d10210 https://play.rust-lang.org/?version=stable&mode=debug&editio... The compiler error says my type didn’t implement clone. But #[derive(Clone)] was right there on my type, and my type was obviously cloneable. The error wasn’t on the derive - or anywhere nearby. My program even compiled successfully, right up until I tried to actually call clone() on my object. And my type trivially, obviously was cloneable because all the fields were clonable. My first thought at the time was that my derive attribute was being ignored by the compiler somehow, but it wasn’t at all obvious why. The compiler’s suggested fix was also wrong and misleading. It suggests adding clone to an irrelevant type that shouldn’t impl clone in the first place. That’s the wrong fix. In summary, the error message doesn’t offer the real problem, which is that the trait bounds added by derive Clone were wrong. And it didn’t suggest the proper fix - which was to impl clone manually. I was very confused for a good while with this one. Get pissy if you want but I find this incredibly counterintuitive and I found the compiler’s error message to be uncharacteristically unhelpful. If this quirk of derive was truly obvious, this blog post wouldn’t have hit the front page of HN in the first place. I cut my hand on one of rust’s sharp edges. Don’t get mad at me for bleeding a little.
    - duped 1y ago
      The error message points you to the inner type and tells you to implement clone for it. Like you point out, it's sometimes not the correct fix - but the compiler can't be smart enough to tell you that. I'm actually at a loss for how this isn't anything but obvious if you know the language and type system. It's not magic! My pet peeve is the learned helplessness around compiler error messages, particularly ones that go to great lengths to be informative and offer solutions instead of just throwing garbage at you.
- estebank 1y ago
  > Aside from anything else, it’d be great if rust had better error messages when you run into this issue. Would you mind filing a ticket detailing what you'd wish the error had been? Without additional context, the only improvement I can think of is adding a note explaining imperfect derives when hitting a missing trait bound coming from a local crate derived impl.
  - josephg 1y ago
    I mentioned in a sibling comment. The error message doesn’t explain or suggest what the problem is, and it recommends the wrong fix. (It suggests implementing clone for T, whereas here you need to manually implement clone). Something like this would have helped me immensely: > Note: even though struct Foo has derive(Clone), Foo does not implement clone in this case. derive(Clone) may have overly restrictive trait bounds (impl Clone where T: Clone). If this is the case, you may need to manually implement Clone for Foo with less restrictive trait bounds: impl Clone for Foo { fn clone(&self) …
    - estebank 1y ago
      Would you mind filing a ticket on GitHub.com/rust-lang/rust with that exact request? (I'm on the go and am not logged on GitHub on this device and wouldn't want this feedback to be lost). This should be relatively easy to add and I agree it would be an improvement.
      - josephg 1y ago
        Sure - will do.
        josephg 1y ago
        https://github.com/rust-lang/rust/issues/143714 https://github.com/rust-lang/rust/issues/143714

by 0rzech 1y ago

0rzech 1y ago

Apparently, Derivative is unmaintained [1], but there is Derive_more [2], Educe [3] and Derive-where [4], if anyone is interested. [1] https://rustsec.org/advisories/RUSTSEC-2024-0388.html https://rustsec.org/advisories/RUSTSEC-2024-0388.html [2] https://crates.io/crates/derive_more https://crates.io/crates/derive_more [3] https://crates.io/crates/educe https://crates.io/crates/educe [4] https://crates.io/crates/derive-where https://crates.io/crates/derive-where

josephg 1y ago

> It's surprising up to the moment the compilation error tells you … Unfortunately this problem only shows up when you’re combining derive with certain generic parameters for the first time. The first time I saw this, I thought the mistake was mine. It was so surprising and confusing that it took half an hour to figure out what the problem was. I thought it was a compiler bug for awhile and went to file it on the rust project - only to find lots of people had beat me to it. Aside from anything else, it’d be great if rust had better error messages when you run into this issue.

duped 1y ago
It took you 30 minutes to understand what "could not call Clone::clone because <type> does not satisfy Clone" means?The error message tells you exactly what the problem is and how to fix it. This is a pet peeve of mine so I'm sorry to be overly dismissive. There are bad error messages out there in the world that are impossible to parse, but this is not one of them. Trying to file a github issue before attempting to understand the error message is insane to me.
- josephg 1y ago
  Yes it took me 30 minutes. The error message in this case is uncharacteristically bad. Or I found it particularly confusing because of quirks in my understanding of rust’s type system. Take a look. Do you think this quirk of derive is obvious from the error message alone? Would you have figured it out, in the context of a much more complex program with dozens of other changes that may or may not have been related? https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f4c0d2a1e93fc80487c8708782d10210 https://play.rust-lang.org/?version=stable&mode=debug&editio... The compiler error says my type didn’t implement clone. But #[derive(Clone)] was right there on my type, and my type was obviously cloneable. The error wasn’t on the derive - or anywhere nearby. My program even compiled successfully, right up until I tried to actually call clone() on my object. And my type trivially, obviously was cloneable because all the fields were clonable. My first thought at the time was that my derive attribute was being ignored by the compiler somehow, but it wasn’t at all obvious why. The compiler’s suggested fix was also wrong and misleading. It suggests adding clone to an irrelevant type that shouldn’t impl clone in the first place. That’s the wrong fix. In summary, the error message doesn’t offer the real problem, which is that the trait bounds added by derive Clone were wrong. And it didn’t suggest the proper fix - which was to impl clone manually. I was very confused for a good while with this one. Get pissy if you want but I find this incredibly counterintuitive and I found the compiler’s error message to be uncharacteristically unhelpful. If this quirk of derive was truly obvious, this blog post wouldn’t have hit the front page of HN in the first place. I cut my hand on one of rust’s sharp edges. Don’t get mad at me for bleeding a little.
  - duped 1y ago
    The error message points you to the inner type and tells you to implement clone for it. Like you point out, it's sometimes not the correct fix - but the compiler can't be smart enough to tell you that. I'm actually at a loss for how this isn't anything but obvious if you know the language and type system. It's not magic! My pet peeve is the learned helplessness around compiler error messages, particularly ones that go to great lengths to be informative and offer solutions instead of just throwing garbage at you.
estebank 1y ago
> Aside from anything else, it’d be great if rust had better error messages when you run into this issue. Would you mind filing a ticket detailing what you'd wish the error had been? Without additional context, the only improvement I can think of is adding a note explaining imperfect derives when hitting a missing trait bound coming from a local crate derived impl.
- josephg 1y ago
  I mentioned in a sibling comment. The error message doesn’t explain or suggest what the problem is, and it recommends the wrong fix. (It suggests implementing clone for T, whereas here you need to manually implement clone). Something like this would have helped me immensely: > Note: even though struct Foo has derive(Clone), Foo does not implement clone in this case. derive(Clone) may have overly restrictive trait bounds (impl Clone where T: Clone). If this is the case, you may need to manually implement Clone for Foo with less restrictive trait bounds: impl Clone for Foo { fn clone(&self) …
  - estebank 1y ago
    Would you mind filing a ticket on GitHub.com/rust-lang/rust with that exact request? (I'm on the go and am not logged on GitHub on this device and wouldn't want this feedback to be lost). This should be relatively easy to add and I agree it would be an improvement.
    - josephg 1y ago
      Sure - will do.
      - josephg 1y ago
        https://github.com/rust-lang/rust/issues/143714 https://github.com/rust-lang/rust/issues/143714