#[key] attribute for derive(Eq, Hash, Ord) as a counterpart to #[default]

language design
1

The Default derive macro has added the ability to select the default member for enums using #[default] attributes which is quite useful, but there's no such feature to selectively derive Ord or Hash which require even more boilerplate to implement correctly.

#[derive(Hash, Ord, PartialOrd, Eq, PartialEq)]
struct S {
  #[key]
  id: u32
  vec: Vec<..>,
}

The lexical ordering would define the sequence that cmp is chained in the generated impl as it is the case today.

This can also be used to explicitly mark fields that contribute to equality so that adding new fields won't accidentally change the semantics.

2

One potential worry that I have about this is that it's plausible for more than one field to be involved in the comparison (and thus part of the key), so you'd want to be able to put #[key] on multiple fields…

…but then you run into the problem that putting #[key] on no fields is meaningful (and should imply a type for which no fields are involved in the comparison and thus all values compare equal). But that would be backward-incompatible with the current use of #[derive(Ord)] and would require a lot more typing than the current case.

Maybe the attribute should be the other way round – marking fields that don't matter for comparison, rather than fields that do. (The latter are probably a lot more common.)

3 Likes
3

There have been some discussions on a general-purpose "skip this field" attribute that might look something like #[skip(Eq, Ord, Hash)].

5 Likes
4

IMO, in complex cases, just write the impl yourself or use a third party crate. Having an attribute to reduce boilerplate in simple cases is already very useful

5

This was actually attempted earlier, exactly using #[skip], but because users can have their own #[proc_macro_derive(Trait, attributes(skip))] - that would conflict with the new built-in attribute #[skip] and cause a compile error

The breakage this caused was deemed too high, so an alternative approach needs to be designed. That is the idea behind re-purposing the conveniently named #[ignore] attribute to fill this purpose, allowing it to apply to fields and variants via #[ignore(Eq, Ord, Hash)]. This avoids breakage because people can't have a helper attribute named ignore, as that is already built-in

I wrote an RFC for this back in October, and so far the feedback was positive, so I will try to make an experimental implementation for this feature soon

8 Likes