I was on the Documentation for the
TypeId trait so I could work on an implementation for the lccc rust standard library, and I noticed that it currently implements
StructuralEq. The implementation intended to be used, which was suggested by @Soni, cannot be perfectly structural (as it may need to fall back to a strcmp of a pointed-to-value). This implementation is a trade off between totally preventing TypeId collisions (where a collision results in unsoundness), and having an efficient PartialEq/Hash.
Currently, the only two things that
StructuralEq is used for are
const_generics (which is unstable) and structural matching of consts. While the latter is stable, it's unusable as it's impossible to create
TypeId in a const context. The former is unstable, but the prescense (or lack thereof) of the StructuralEq implementation on
TypeId does affect the well-formedness of a declaration like
struct Foo<const T: TypeId>;, despite the fact that the type constructor is uninstantiatable (for now).
My question is, is the fact that
StructuralEq/StructuralPartialEq an artifact of the rustc implementation using
derive(PartialEq,Eq), or is it intended that, in the future, either or both of
const_generics and const patterns will work with