Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a TypeID intrinsic #9913

Closed
Kimundi opened this issue Oct 17, 2013 · 5 comments
Closed

Add a TypeID intrinsic #9913

Kimundi opened this issue Oct 17, 2013 · 5 comments
Labels
A-typesystem Area: The type system

Comments

@Kimundi
Copy link
Member

Kimundi commented Oct 17, 2013

It's needed for things like an Any type, or safe dynamic loading.

It basically needs to be an generic intrinsic that returns some kind of data structure that uniquely identifies the generic type it has been instantiated with. Ideally it also includes information about the crate itself and it's meta data, so that two different named and/or versioned crates with the same type result in different TypeIDs.

Currently, the static pointers to type descriptors can be kinda used for this, but there is no guarantee that a type descriptor can not be duplicated, so using them for this purpose is incorrect.

Possible usage could look like this:

fn same_types<T, U>() -> bool {
    let type_id_t = intrinsics::type_id::<T>();
    let type_id_u = intrinsics::type_id::<U>();

    type_id_t == type_id_u
}

fn main() {
    assert!(same_types::<uint, uint>());

    let type_id = intrinsics::type_id::<std::util::Void>();
    assert!(type_id.path().to_str() == "<6df45e453>::std::util::Void");
    assert!(type_id.crate().name() == "std");
    assert!(type_id.crate().version() == "1.0");
    assert!(type_id.crate().hash() == "6df45e453");

}

See also https://gist.github.com/Kimundi/6802198 for some prototype implementation of a TypeID using type descriptors.

@brson
Copy link
Contributor

brson commented Oct 25, 2013

Nominating.

@orenbenkiki
Copy link

Comparing TypeId for equality is great, but it would also be very nice if it were possible to access the names of the types, especially for error messages. Would it be possible for TypeId to offer a name() -> &'static str (or maybe ~str) method?

I know unique names of types across different crates are tricky, but even if given only the unique name within the defining crate, this would be extremely useful for debugging dynamic type errors.

@alexcrichton
Copy link
Member

I don't think that the type id is the right location for the name, but there is a name field on the TyDesc, and that can be called for arbitrary types. Additionally, you may also be able to use the TyVisitor to build the name of a type.

@orenbenkiki
Copy link

Fair point... that said, it seems silly we have TypeId and TyDesc and no relationship between them. Doesn't it make sense to unify them both (e.g., add Eq to TyDesc)? Or, barring that, at least provide an easy way to get one from the other?

@alexcrichton
Copy link
Member

That's not a bad idea unifying them. I think right now the blocker for that is that type_id is only defined for T: 'static where get_tydesc is defined for all T. If we can lift that restriction, I think it would be a bit easier to unify the two of them, but for the time being it may be difficult to do so.

bors added a commit that referenced this issue Nov 4, 2013
…akis

This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
bors added a commit that referenced this issue Nov 5, 2013
…akis

This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

4 participants