Skip to content

A unique string key for TypeId #694

Open
Open
A unique string key for TypeId#694
Labels
T-compilerRelevant to the compiler team, which will review and decide on the RFC.T-libsRelevant to the library team, which will review and decide on the RFC.

Description

@steveklabnik
steveklabnik
opened on Jan 21, 2015

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.

Activity

  1. steveklabnik
    added
    A-wishlist
    on Jan 21, 2015

  2. mzabaluev commented on Jan 21, 2015

    @mzabaluev
    mzabaluev
    on Jan 21, 2015
    Contributor

    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.

  3. steveklabnik commented on Jan 21, 2015

    @steveklabnik
    steveklabnik
    on Jan 21, 2015
    ContributorAuthor

    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.

  4. mzabaluev commented on Jan 21, 2015

    @mzabaluev
    mzabaluev
    on Jan 21, 2015
    Contributor

    Re-connecting to #664.

  5. thestinger commented on Jan 21, 2015

    @thestinger
    thestinger
    on Jan 21, 2015

    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.

  6. thestinger commented on Jan 21, 2015

    @thestinger
    thestinger
    on Jan 21, 2015

    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.

  7. mzabaluev commented on Jan 21, 2015

    @mzabaluev
    mzabaluev
    on Jan 21, 2015
    Contributor

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

  8. thestinger commented on Jan 21, 2015

    @thestinger
    thestinger
    on Jan 21, 2015

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

  9. thestinger commented on Jan 21, 2015

    @thestinger
    thestinger
    on Jan 21, 2015
    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();
}

  10. thestinger commented on Jan 21, 2015

    @thestinger
    thestinger
    on Jan 21, 2015

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

  11. mzabaluev commented on Jan 21, 2015

    @mzabaluev
    mzabaluev
    on Jan 21, 2015
    Contributor

    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.

  12. petrochenkov
    added
    T-libs-api[DEPRECATED; DO NOT USE]
    T-compilerRelevant to the compiler team, which will review and decide on the RFC.
    on Jan 28, 2018
  13. petrochenkov
    removed
    A-wishlist
    on Feb 24, 2018

  14. bjorn3 commented on Aug 17, 2023

    @bjorn3
    bjorn3
    on Aug 17, 2023
    Member

    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

  15. thomcc commented on Aug 17, 2023

    @thomcc
    thomcc
    on Aug 17, 2023
    Member

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

  16. clarfonthey
    added
    T-libsRelevant to the library team, which will review and decide on the RFC.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-compilerRelevant to the compiler team, which will review and decide on the RFC.T-libsRelevant to the library team, which will review and decide on the RFC.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions