Why not impl Eq for globset::GlobMatcher?

[YeungOnion]

Not a push to do this, but to understand if I'm missing something.

I noticed that globset::Glob implements Eq relying on two variables that implement Eq,

• glob: String
• opts: GlobOptions

but not re: String^*. And it seems safe as the consistency between glob: String and re: String has - as far as I can tell - been completely enforced. I think that would mean that a GlobMatcher only has one data and then there's a "cached" equivalent data.

So would it be safe to impl Eq for GlobMatcher just using Glob::eq, or am I missing something?

^* I'd expect this may be doable under the constraint of globs, but unsure about full regex. But I think tougher than needed.

[BurntSushi]

I don't think there's any particular reason. And to be honest, I'm not a huge fan of implementing PartialEq or Eq on Glob (or GlobSet) itself. There's an ambiguity there about what PartialEq/Eq actually means. For the regex crate, for example, I chose not to implement PartialEq/Eq for Regex for what is essentially that reason: does equality mean that the same pattern was used to build two distinct Regex values, or does equality mean that the two distinct Regex values match precisely the same set of strings? The latter has a precisely defined meaning for regular languages, but is unfortunately quite expensive to compute. I reckon the same is true of globs. For example, should the two globs a and [a] be considered equivalent or not? If one uses the concrete syntax (as globset currently does), then they are not equivalent. But if one defines equality in terms of what they actually match, then they are not equivalent.

With all that said, PartialEq/Eq implementations are undoubtedly useful in practice, because they enable Regex values (or Glob values) to be used in other data structures that require such implementations (such as btrees or hashmaps). So there is a practical consideration here, but still, it's not totally clear that it is the right thing to do.

[BurntSushi]

The globset crate does have a slightly different circumstance than the regex crate in that there is a Glob and a GlobMatcher. But the decision from the regex crate suggests that neither should implement PartialEq/Eq. Probably either both should implement PartialEq/Eq or neither should.