implement PartialEq, Eq and Hash

[ashfordneil]

Without these traits being implemented, it is difficult to store Regex structs, or types containing them, in collections such as HashSet and HashMap. It also prevents any type containing a Regex from automatically deriving these traits. Would it be okay to implement these traits for the Regex struct, perhaps just using the as_str() function and performing comparisons / hashes on the output of that?

[BurntSushi]

regex 0.1 had this impl, but I removed it. It's way too misleading because finite state machines actually have a concept of equality that is very different from "do these regex strings match."

You should solve this by putting your Regex in a newtype and deriving the traits you want.

[BurntSushi]

See #178 and #313

[therustmonk]

Information for those who got here. A naive comparison can be implemented this way:

struct Wrapper {
    regex: Regex,
}

impl PartialEq for Wrapper {
    fn eq(&self, other: &Self) -> bool {
        self.regex.as_str() == other.regex.as_str()
    }
}

[casey]

Not to necro an old issue, but I wonder if not having these implementations is worth it.

If I understand correctly, the benefit of not having these implementations is that if a user expects the == for Regex to compare the underlying abstract state machines of the regex, then they will be surprised when it doesn't.

(And it can't be implemented that way, because it's expensive to compute, and == is generally expected to be fast.)

However, I'm not sure if that's what users actually expect. Personally, I would expect == to just do string comparison, and would be surprised if \d+ == \d\d* was true.

Even if it was fast, comparing the underlying of the regex behavior might also be undesirable, since could you not have two regexes which compare true, since they match the same set of strings, but which have large efficiency differences? I.e., one is much more efficient than the other, and terminates much faster. In such a case, I'm not sure you would want == to return true, and obscure the differences between them.

The downside of not having these implementations, or at least the downside that I've personally run into, is that if you include a Regex in another type, and then want to derive ParitalEq, Eq, or Hash, you can't, because Regex doesn't implement them.

I ran into this while implementing a config file that contains a regex:

#[derive(Deserialize)]
struct Config {
  some_other_value: u32,
  #[serde_as(as = "DisplayFromStr")]
  regex: Regex,
}

I wanted to do this in a test:

assert_eq! {
  Config::load("path.yaml"),
  Config { regex: Regex::new("hello").unwrap() },
}

But can't do so because I can't derive PartialEq for Config. Another case of this that I've run into is when deriving clap::Parser derive where an argument is a Regex, and I can't add tests which exercise how arguments are parsed using assert_eq!(…).

Feel free to ignore this comment! Don't want to force you to relitigate an old issue, I just wanted to add my 2¢.

[dolezvo1]

Yeah, PartialEq implementation would definitely be nice to have for testing purposes. There doesn't seem to be a way to compare the matching options manually outside of the crate, and even if there were a way to do that, the code would be rendered incorrect if a new matching option were added in the future. Are the users of this library just expected to not test their code?