A unique string key for TypeId

[steveklabnik]

Issue by mzabaluev
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 from TypeId or a similar API.

Now, it's likely that TyDesc names are sufficiently unique, and hash collisions on TypeId break the world as Rust knows it (#17179) so the u64 hash value can be used as practically unique, but: 1) uniqueness constraints on any of those are not documented; 2) access to TyDesc is unsafe.

[mzabaluev]

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.

[steveklabnik]

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.

[mzabaluev]

Re-connecting to #664.

[thestinger]

I don't really understand this request. The TypeId integer must be unique or types like Any would 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.

[thestinger]

What is wrong with just using the byte representation of the TypeId integer? The endianness could be normalized if necessary, or it could just be converted to a number in a specific base.

[mzabaluev]

@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.

[thestinger]

Sadly, I don't think the way Rust produces the user-facing type strings results in unique names.

[thestinger]

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();
}

[thestinger]

At a minimum, Rust would need to consider functions as being module namespaces in order for the current names to be unique.

[mzabaluev]

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.

[bjorn3]

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

[thomcc]

Nothing prevents the string approach from happening in the future, that wasn't the intention of the size increase.