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).
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)andderive(Eq)are special, and interacts with various language features. In particular, types likeString(suprisingly) have theStructuralEqimpl thatderive(Eq)presents. Another example isTypeId, which is currently bothStructuralEqandStructuralPartialEq, so it could be used in structural matching ofconsts 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::offunctionconst, would bindTypeIdto 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 withTypeIdas 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).