StructuralEq and derive(PartialEq,Eq) in the stdlib

[chorman0773]

I've been meaning to open this for a few weeks now, but haven't had the time.

Currently, in the implementation of the rust standard library, many types use derive(PartialEq,Eq). While, for other derive macros, this isn't an issue, derive(PartialEq) and derive(Eq) are special, and interacts with various language features. In particular, types like String (suprisingly) have the StructuralEq impl that derive(Eq) presents. Another example is TypeId, which is currently both StructuralEq and StructuralPartialEq, so it could be used in structural matching of consts and (eventually) in const generics.
This particularily affects an implementation I am working on here, which is intended to solve a longstanding soundness issue involving TypeId collisions, at the cost of a non-structural PartialEq implementation. While this is not currently an issue, the stablization of const generics, or making the TypeId::of function const, would bind TypeId to an implementation similar to what already exists, on all implementations (and, in any case, will run into #10389 at some level). For example, with the #[feature(const_generics)], it is currently possible to declare a type with TypeId as a generic parameter (though it's not possible to instantiate that parameter).

I have previously described the TypeId issue on IRLO, and the more general issue on zulip.
I maintain my recommendation from the zulip thread, that currently, if a type cannot be used in structural matching of constants, the derive be removed and replaced with something effectively similar (possibly an equivalent, unstable, derive macro that excludes the impls of Structural{Partial,}Eq).

[programmerjake]

maybe change the title to disambiguate from other derive(PartialEq) issues? (such as forcing both lhs and rhs to have matching lifetimes.)

[RalfJung]

Also see #74446 -- StructuralEq in its current form is mostly ad-hoc; I think we need to go back to the drawing board and think properly about what it is we want this trait to express. Under what I imagine, String would autmomtically cease to be StructuralEq (since it contains a raw pointer field, indirectly).

But I agree TypeId should probably not be allowed as a const generic parameter.