Repository navigation
A unique string key for TypeId #694
Description
Activity
Begging for an "Easy" label since the building blocks seem to be available.🙏 Update: unique meaningful names may be actually not easy to reach from the current state.We don't have a ton of labels yet. I want to triage everything first, and then plan on going through the wishlist label and adding stuff like easy/hard.
Re-connecting to #664.
I don't really understand this request. The
TypeIdinteger must be unique or types likeAnywould be memory unsafe. It's true that Rust doesn't implement it in a sane way where collisions are guaranteed to be caught or infeasible, but there's already a non-feature-request bug for that.What is wrong with just using the byte representation of the
TypeIdinteger? The endianness could be normalized if necessary, or it could just be converted to a number in a specific base.@thestinger As mentioned in the description, the integer may be good enough (though only available via
hash()which is unfortunately named, as it brings collisions into mind). But if a process-unique name would be available, mangled or clear, I'd like to use that rather than a hex string from the hash, for better diagnostics.Sadly, I don't think the way Rust produces the user-facing type strings results in unique names.
use std::intrinsics::get_tydesc; mod foo { pub struct Baz; } fn foo() { struct Baz; unsafe { println!("{}", (*get_tydesc::<Baz>()).name); println!("{}", (*get_tydesc::<foo::Baz>()).name) } } fn main() { foo(); }
At a minimum, Rust would need to consider functions as being module namespaces in order for the current names to be unique.
In fact, it's easy to achieve both requirements on my side, by simply combining the hash and the human-readable name. It would still be nice to get the name safely available, though.
- addedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]T-compilerRelevant to the compiler team, which will review and decide on the RFC.Relevant to the compiler team, which will review and decide on the RFC.
on Jan 28, 2018 In the end we increased the TypeId size to 128bit: rust-lang/rust#109953 Using strings didn't end up happening: rust-lang/rust#95845
Nothing prevents the string approach from happening in the future, that wasn't the intention of the size increase.
- addedT-libsRelevant to the library team, which will review and decide on the RFC.Relevant to the library team, which will review and decide on the RFC.and removedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Aug 18, 2026
Tuesday Jan 13, 2015 at 22:40 GMT
For earlier discussion, see rust-lang/rust#21116
This issue was labelled with: A-libs, A-typesystem in the Rust repository
I want to implement a mapping of
Box<T: 'static>to GType. That dynamic type system requires process-unique type names. So I'd like to have a process-unique key, preferably a string, available fromTypeIdor a similar API.Now, it's likely that
TyDescnames are sufficiently unique, and hash collisions onTypeIdbreak the world as Rust knows it (#17179) so theu64hash value can be used as practically unique, but: 1) uniqueness constraints on any of those are not documented; 2) access toTyDescis unsafe.