Stabilize const_type_id feature

[KodrAus]

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 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:

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:

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:

#![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.

[rust-highfive]

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

r? @ecstatic-morse

[ecstatic-morse]

I don't see any hazards from this. The result of type_id is allowed to change across compiler versions, but I think that is acceptable for const fn.

cc @rust-lang/wg-const-eval

[RalfJung]

Cc @rust-lang/lang because this is about const-stabilizing an intrinsic.

[Y0ba]

What about collisions #10389? Currently this API is really dangerous to use and there is no way to detect collisions even without using dylibs. Not really related to const-stabilization but in current shape it's pretty useless both in const and in runtime.

[ecstatic-morse]

In my opinion, the fact that type_id is poorly implemented doesn't have any bearing on whether or not it can be const. All code that uses Any is using type_id under the hood, so it's not "pretty useless". While I totally agree that the chance of a hash-collision is a serious problem, saying it's "really dangerous" is an overstatement for the vast majority of programs: The probability of a 64-bit hash collision in a program with 100,000 types is on the order of 1 in 10 billion.

[Y0ba]

It''s possible to intentionally find type_id collisions.

Unfortunately it's possible to hit collisions unintentionally.

Why should that affect const-stabilization?

Because there will be more ways to hit it. That's what I wanted to say. I'd rather see that feature deprecated and switch Any trait to safer alternative.

[KodrAus]

Ah looks like I’ve got a test to fix up:

error[E0635]: unknown feature `const_type_id`
12379
  --> /checkout/src/test/ui/consts/issue-73976-monomorphic.rs:8:12
12380
   |
12381
LL | #![feature(const_type_id)]
12382
   |            ^^^^^^^^^^^^^
12383

12384
error: aborting due to previous error

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 9d4818c has been approved by nikomatsakis

[bors]

⌛ Testing commit 9d4818c with merge 6fd4c3f...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: nikomatsakis
Pushing 6fd4c3f to master...

[jplatte]

Stability attribute is 1.46, has to be updated to 1.47.

[eddyb]

Just came across this, some of the people involved in this might be interested in #75923 (comment).

[scottmcm]

Interesting, eddyb. FWIW I'd be fine with reverting this on beta under a "new information came in that made us not confident in the promise any more" justification. Wouldn't be the first rolled-back stabilization...

[RalfJung]

See this discussion for why stabilization was likely premature, and we should take it back before the release.

@KodrAus can you create the PR that reverts this, or should I?