Tracking issue for type_id stabilization

[aturon]

The method get_type_id in Any is intended to support reflection. It's currently unstable in favor of using an associated constant instead.

[bluss]

It was pointed out it's one of the very few methods to be named with get_ prefix, so it could be renamed to just type_id().

[aturon]

I suspect this is just some very old convention that wasn't updated during stabilization (since we didn't stabilize this API).

[flosse]

Any progress here?

[Zaerei]

I tried to tackle it, but it looks like the main problem is that TypeId::of isn't constant and can't be constant. It calls intrinsics::type_id which, on any attempt to make it a const function yields the cryptic error "unmatched visibility pub". This would be a simple change if TypeId::of was a const fn.

(Though making an extern function const is probably dicey from a compiler perspective anyway, I'm not an expert on that).

[alexcrichton]

Removing nomination as this was an accidental mistake about what this issue was about.

[fschutt]

Any update on this? Is is discouraged to use it in current code?

[jweinst1]

Is there any other way to do reflection or dynamic typing that will work?

[SimonSapin]

@jweinst1 the rest of the std::any::Any trait is stable:

fn is<T>(&self) -> bool where T: Any;
fn downcast_ref<T>(&self) -> Option<&T> where T: Any;
fn downcast_mut<T>(&mut self) -> Option<&mut T> where T: Any;
fn downcast<T>(Box<self>) -> Result<Box<T>, Box<Any>> where T: Any ;

In each of these the call site is specifying a specific T. (Internally the implementations of these method compare Self::type_id() and T::type_id().)

[SimonSapin]

I’ve just realized that TypeId and TypeId::of are also stable, so you could copy the Any trait into your own code.

[Mark-Simulacrum]

I propose we make TypeId::of a constant function. This should be a rather trivial step, primarily just adding it to the list of constant intrinsics as far as I can tell. (@eddyb Can you confirm?).

Once that's done, we can add a constant to Any and Error that'll replace the currently unstable methods associated with both, and stabilize those.

---

@SimonSapin I don't think it's that easy since there exist methods in the wild that pass around trait objects (&Any and &Error) and since we don't have trait object casts today (if we ever will, not sure if it's possible, seems like perhaps not) without these constants/methods there's not a way to retrieve the underlying type of a trait object.

[sfackler]

It might be better off as an associated constant if possible.

[Mark-Simulacrum]

I might not be understanding, but I think that's what I suggested? That we have something like const TYPE_ID: TypeId = TypeId::of::<Self>(); in Any and Error?

[sfackler]

Oh right derp, there isn't anywhere to put the constant on TypeId itself since it isn't parameterized.

[Badel2]

Alright, I'm working on this and I think I managed to turn type_id into a constant intrinsic, meaning I can do const A: TypeId = TypeId::of::<T>();, however when I try to add it to the Any trait I get an error (E0038) that says "the trait cannot contain associated consts". Anyway, I'll add a test and submit a PR.

Edit: I solved the mistery, the const needs to be inserted in the impl Any block, not in trait Any. This can be done after the next stage0.

[glaebhoerl]

I wonder if #10389 is relevant here

[Badel2]

It turns out that associated constants cannot be used in trait objects, because the constants aren't stored in the vtable. So this won't work:

trait Any {
    const TYPE_ID: TypeId = TypeId::of::<Self>();
}

And this also won't work, because it just stores the TypeId of the Any trait object, not the TypeId of the type that implements Any:

trait Any {}
impl Any {
    const TYPE_ID: TypeId = TypeId::of::<Self>();
}

So assuming we still want to make TYPE_ID an associated constant, we need to add support for associated constants in trait objects, or make this a special case and add a dedicated field to the vtable which stores the TypeId.

[SimonSapin]

we need to add support for associated constants in trait objects

I think this wouldn’t work? This code:

fn foo(object: &Any) {
    let type_id = object.get_type_id();
}

… can call a trait method from a trait object. Accessing an associated constant would be <T as Any>::TYPE_ID, but this code does not know what T is.

Other code that does have a concrete T type can use TypeId::of::<T>(), which is now a const fn.

So I propose keeping this method as a method, renaming to type_id to remove the get_ prefix, and stabilizing.

[sfackler]

That seems reasonable.

[SimonSapin]

I propose keeping this method as a method, renaming to type_id to remove the get_ prefix, and stabilizing.

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[sfackler]

Seems like we might as well make it a const method while we're stabilizing it. It should be pretty trivial since TypeId::of is already const.

[SimonSapin]

Lots of implementation details in the standard library are pema-unstable

It’s fine that those implementation details exist, but we should be clear about what items are in that category as opposed to features that are not stable yet but have some path to stabilization. Perma-unstable implementation details have #[doc(hidden)] and no tracking issue.

The existence of this open tracking issue indicates that there is something to be tracked. Closing it and deciding that get_type_id should be a hidden implementation detail is one possible resolution.

[ExpHP]

Hm? Did rfcbot not register the concern here? I thought it normally edits those into its post.

[leodasvacas]

We want to revisit trait objects in general soon after the 2018 edition stuff is done.

Unfortunate timing, considering a new syntax will be introduced for them. This would otherwise be a good opportunity to introduce small breaking changes to behavior. But I guess that's off topic here.

[rfcbot]

The final comment period is now complete.

[tmccombs]

I figured we'd hold off on stabilizing this as it requires some form of rustc storing constants in vtables (which is currently unimplemented).

Are there any plans to implement this, or RFCs that specify that?

[Diggsey]

@withoutboats

I'm not certain that there's a benefit to stabilizing this. If I want to create a downcastable trait object, I have to define my own get_type_id in that trait anyway (see the mopa crate for example).

That's the exact motivation for stabilising this: as a trait method it is directly callable on trait objects extending Any. That means that mopa and the like can get rid of their custom Any traits, which I view as a significant benefit.

This issue is even directly linked from comments in the mopa source code: https://github.com/chris-morgan/mopa/blob/master/src/lib.rs#L163

We should stabilize this as-is - I don't see how performance is a concern since we already have TypeId::of for the static case, and we're still leaving open the possibility of adding it as an associated constant if trait objects gain support for them.

[tmccombs]

Unfortunately I think there may be a bug in fcp where I registered a blocking concern to block stabilizing this method but it didn't halt the FCP process.

From #49613 (comment)

@Centril should this have the finished-final-comment-period label?

See also, #27745 (comment)

[Centril]

@tmccombs unclear; I defer to @rust-lang/libs

[TimDiekmann]

How likely is this to be stabilized? Will the _get prefix be removed?

[SimonSapin]

Very, since FCP to stabilize is done. Yes, since that’s was part of the FCP proposal.

Stabilization PR: #57834

[TimDiekmann]

Thank you @SimonSapin. I wasn't sure since the FCP was months ago.

[SimonSapin]

Yeah, sometimes we just forget to follow up. Pinging open issues like you did can help, thanks!