`TypeId: StructuralEq` is this necessary or planned to be useful in the future?

libs
1

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 StructuralPartialEq and 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 TypeId implements 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 TypeId?

3 Likes
2

To be clear, the above is not the start of a proposal to constrain the implementation of TypeId. Rather it's a question of issues presented by using this particular implementation of TypeId, as part of a different implementation of rust, going forward (at least until an ABI break is warranted), in terms of all features which are intended to be stablized now or in the future and the semi-guarantees made by the rustc implementation.

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.