Repository navigation
StructuralEq trait docs are outdated #115881
Description
The StructuralEq trait docs are saying
/// In a more ideal world, we could check that requirement by just checking that
/// the given type implements both the `StructuralPartialEq` trait *and*
/// the `Eq` trait. However, you can have ADTs that *do* `derive(PartialEq, Eq)`,
/// and be a case that we want the compiler to accept, and yet the constant's
/// type fails to implement `Eq`.
///
/// Namely, a case like this:
///
/// ```rust
/// #[derive(PartialEq, Eq)]
/// struct Wrap<X>(X);
///
/// fn higher_order(_: &()) { }
///
/// const CFN: Wrap<fn(&())> = Wrap(higher_order);
///
/// fn main() {
/// match CFN {
/// CFN => {}
/// _ => {}
/// }
/// }
/// ```
///
/// (The problem in the above code is that `Wrap<fn(&())>` does not implement
/// `PartialEq`, nor `Eq`, because `for<'a> fn(&'a _)` does not implement those
/// traits.)
///
/// Therefore, we cannot rely on naive check for `StructuralPartialEq` and
/// mere `Eq`.
However, with the FnPtr trait, fn(&()) does implement Eq and PartialEq.
Is the StructuralEq trait still necessary? Eq has no methods, so if PartialEq is structural then there's no way that Eq is not, right?
Activity
RalfJung commentedon Sep 15, 2023
Cc @rust-lang/types
RalfJung commentedon Sep 16, 2023
Also I don't think the current consensus is that we should check matched constants to be
Eq. #84045 got rejected, which is a fairly clear sign thatPartialEqis sufficient for matching and everything else can be handled with lints.So I don't think
StructuralEqstill serves any purpose.nikomatsakis commentedon Sep 16, 2023
I would be very happy to settle this story once and for all. I still feel a bit confused about our plan here, though I recall thinking @RalfJung that your proposals made sense to me.
RalfJung commentedon Sep 16, 2023
I think my prior proposals don't entirely work any more with things like #67343 or code like this -- we have really honed in on StructuralPartialEq being a shallow property, not a statement about being able to create valtrees. We also have
ConstParamTyas a separate trait now; I think that might be closer to what I originally imagined.On the plus side, I seem to recall @lcnr was set on keeping StructuralPartialEq shallow; so maybe it's easier to come to an agreement now that I've come around to accepting that. :)
Also see this Zulip thread I just started.
Auto merge of rust-lang#116167 - RalfJung:structural-eq, r=lcnr
Auto merge of rust-lang#116167 - RalfJung:structural-eq, r=lcnr
Auto merge of rust-lang#116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr
Auto merge of #116167 - RalfJung:structural-eq, r=lcnr