RFC: Allow #[ignore(Trait)] on field to ignore it when deriving Trait

[nik-rev]

This RFC proposes that the #[ignore] attribute can now be applied to fields.
Its purpose is to tell derive macros to ignore the field when generating code.

#[derive(Clone, PartialEq, Eq, std::hash::Hash)]
struct User {
    #[ignore(PartialEq, std::hash::Hash)]
    //       ^^^^^^^^^  ^^^^^^^^^^^^^^^
    //       traits that will ignore this field
    name: String,
    #[ignore(PartialEq, std::hash::Hash)]
    age: u8,
    id: u64
}

For the above struct User, derives PartialEq and Hash will ignore the name and age fileds.
Code like this is generated:

impl Clone for User {
    fn clone(&self) -> User {
        User {
            name: self.name.clone(),
            age: self.age.clone(),
            id: self.id.clone(),
        }
    }
}

impl PartialEq for User {
    fn eq(&self, other: &User) -> bool {
        self.id == other.id
    }
}

impl Eq for User {}

impl std::hash::Hash for User {
    fn hash<H: std::hash::Hasher>(&self, state: &mut H) -> () {
        std::hash::Hash::hash(&self.id, state)
    }
}

Rendered

[fmease]

This can and should probably be an ACP, not an RFC.

CC rust-lang/libs-team#334 from >1 year ago which proposed something very similar for Debug. Its implementation had to be blocked because adding new helper attributes to built-in derive macros in core/std is a breaking change (due to lack of "hygienic" or namespaced helper attrs). See link for details.

Similarly, starting to interpret your proposed #[ignore] as a helper attribute is not backward compatible without extending the language (via separate proposals) as alluded to above (not only due to the feature gate error but also due to any validation that's performed).

(We got away with the addition of #[default] for Default either because we were lucky or because it was deemed acceptable at the time (I'd have to dig into the history to find out the specifics) but in general that's not principled and goes against Rust's stability guarantees.)

[nik-rev]

This can and should probably be an ACP, not an RFC.

CC rust-lang/libs-team#334 from >1 year ago which proposed something very similar for Debug. Its implementation had to be blocked because adding new helper attributes to built-in derive macros in core/std is a breaking change (due to lack of hygienic or namespaced helper attrs). See link for details.

Published it as an RFC that is what was suggested in this comment

Validation: The following doesn't compile due to a deny-by-default future incompatibility lint which is going to be promoted to a hard error as part of this RFC:

use derive as ignore;

struct Foo {
    // syntax that will gain meaning because of this RFC
    #[ignore()]
    hello: ()
}

This does not compile because of ambiguity. Whereas if ignore wasn't already built-in, then it would which would be breaking

use derive as ignore;

struct Foo {
    #[ignore]
    hello: ()
}

So then giving this meaning should be fine:

use derive as ignore;

struct Foo {
    #[ignore(Foo, Bar)]
    hello: ()
}

struct Foo {
    #[ignore(Foo, Bar)]
    hello: ()
}

Because it would not have compiled (without turning off the deny-by-default lint which says that we will promote it into a hard error in the future)

This currently does compile, with a warn-by-default lint. And in the RFC I'll clarify that this will continue to compile, and its meaning will not be changed.

struct Foo {
    #[ignore]
    hello: ()
}

I'm not super familiar with terminology, but this isn't a new helper attribute - it's the same attribute #[ignore] that is re-purposed for this proposal.

Summary: If any other name was chosen, then it could be potentially breaking. But because ignore is already a built-in attribute, I think it won't cause breakage aside from upgrading the deny-by-default future incompatibility lint from 6 years ago to an error

If there are any possible breaking changes that I've missed, I would appreciate an example

[fmease]

Ah, I completely forgot that #[ignore] is of course already a built-in attribute. In that case, it looks like it's indeed backward compatible, thanks for the correction :)

Still, it would "need to become" a helper attribute but that would clash with the built-in attribute, or rather the built-in attribute #[ignore] (used for ignoring tests) would take precedence under the current rules.

However, I'm not an expert in those resolution rules, so maybe it's a non-issue, so I'm happy to be corrected by someone more knowledgeable. I'm wondering if we can properly discern helper and built-in attribute #[ignore] inside ADTs under #[derive]s without some sort of hacks (e.g., not resolving #[ignore] to the built-in attr if it's on a field or variant; there's no precedent for that AFAIK).

[fmease]

CC https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/ (from Jul–Sep '25) (don't quite remember if this is only tangentially related or indeed fully)

[madsmtm]

Really elegant solution with transforming #[ignore(Xyz)] -> #[ignore]!

[ElchananHaas]

Does this feature's benefits outweigh implementation complexity?

#[derive(Clone, PartialEq, Eq, std::hash::Hash)]
struct User {
    #[ignore(PartialEq, std::hash::Hash)]
    //       ^^^^^^^^^  ^^^^^^^^^^^^^^^
    //       traits that will ignore this field
    name: String,
    #[ignore(PartialEq, std::hash::Hash)]
    age: u8,
    id: u64
}

This could be replaced with manual implementations of std::hash:Hash, Eq and PartialEq on the id field. This works if there is only 1 or 2 fields used for the trait implementation.

If there is a single field that needs ignoring it can be newtyped and given manual trait implementations. For example

struct OpaqueRng {
    //hidden fields - pretend these don't exist in eq and partialeq comparisons. 
}

impl PartialEq for OpaqueRng {
    fn eq(&self, other: &OpaqueRng) -> bool {
       true
    }
}

now OpaqueRng can be used in any struct without needing this RFC. This covers the case where there is only a few fields that should be ignored.

Are there any motivating cases in the middle where neither approach works well?

[programmerjake]

Does this feature's benefits outweigh implementation complexity?

I think it does because of how common it is to want to ignore some fields, that imo outweighs all the additional compiler complexity.
I have probably 10 different structs that do that in the codebase I'm currently working on, and that's despite all the extra boilerplate that doing that currently needs.

[kennytm]

Currently when you #[derive(PartialEq)] the compiler will automatically implement StructuralPartialEq too (#3535). If any field is #[ignore(PartialEq)]'ed should we still consider the type having structural equality?

[nik-rev]

Currently when you #[derive(PartialEq)] the compiler will automatically implement StructuralPartialEq too (#3535). If any field is #[ignore(PartialEq)]'ed should we still consider the type having structural equality?

If, while deriving PartialEq any field is ignored, then invariants of StructuralPartialEq will not be upheld - so it will not be automatically implemented

66d404d