Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #72488 - KodrAus:stabilize/const_type_id, r=nikomatsakis
Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature, which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage, but I’ve included some more below. As a simple example, you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::<u32>(), TypeId::of::<i32>(), ]; assert_eq!(TypeId::of::<u32>(), TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::<Self>(); } impl<T: 'static> Any for T { } assert_eq!(TypeId::of::<usize>(), usize::TYPE_ID); ``` `TypeId::of` is generic, which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property, which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of`, other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions, so violating it using type ids isn’t new. As an example of how impls can behave differently, you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self`, rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::<Self>`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::<usize>(); match TypeId::of::<Self>() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }), // For other types, dispatch to the generic `Self::default`. _ => Self::default, } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl<T: fmt::Debug + 'static> Specialized for T { fn default(x: &Self) { println!("default: {:?}", x); } fn usize(x: &usize) { println!("usize: {:?}", x); } } // Will print "usize: 42" Specialized::call(&42usize); // Will print "default: ()" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions, it's never valid to cast a type id to its underlying value.
- Loading branch information
