Derive Eq and Hash for ControlFlow by inquisitivecrystal · Pull Request #103084 · rust-lang/rust (original) (raw)

But I am a tiny bit skeptical of their utility, and conceptually, I do somewhat wonder what it means to "compare" two different "control flow" values. But maybe I am being too conservative here. And in particular, I can't think of anything specifically bad about these impls, although I do question in what use cases they are useful. (Beyond the, e.g., CONTINUE constant, which I am more skeptical about for already stated reasons.)

When you say "compare", that makes me think of PartialOrd and Ord, which aren't being proposed. Equality comparisons are already allowed, since we implement PartialEq. This really isn't allowing any new operations, in terms of the semantics of the type.

I think we really ought to add the Eq derivation, just on the grounds of being a good neighbor. It's a marker trait: since equality comparisons on this type are total equality comparisons, it makes sense to mark them as such. In addition, there's no reason to prevent users from creating their own constants and using them in matches, even if we end up removing CONTINUE.

I don't actually have a use case in mind for Hash, but I'm not sure we really need one. Just to give a general direction, a use for this might involve memoization or the like. Result already implements Hash, so this is does provide parity with that.

Unlike PartialOrd and Ord, these operations are consistent with the operations that are already meaningful for the type. They just make it more interoperable and pleasant to use. As a final point, the Rust API guidelines say that types should eagerly implement common traits. If these operations are meaningful, the question becomes why we wouldn't want to add them.

Sorry for going into "passionately list all the reasons why we should totally do this" mode. Bad habit of mine.