Mark Any::get_type_id as experimental

[reem]

It is likely going to be removed and replaced
with an associated static.

[emberian]

cc @aturon

[alexcrichton]

I don't think that associated statics are on the roadmap for 1.0, so this may have to be stable at 1.0 due to a lack of other method of implementing it.

[aturon]

That was my initial thought, but we don't necessarily need to expose the type_id aspect here in the stable channel for 1.0; we could still stabilize the checked downcasting based on it.

@reem how would you feel about get_type_id only being usable on Nightly at 1.0? I know you're one of the key people using it right now.

[emberian]

Is there a reason something can't be experimental/unstable but still in the release channel? For example, as an internal implementation detail of some libraries..

[aturon]

@cmr Experimental/unstable items can be used internally in libstd or the compiler, which is why we can still expose a stable checked downcast operator.

As far as the broader policy point, it's all laid out in the blog post on stability.

[reem]

@aturon as long as TypeId::of is available I am ok as this can be emulated out of tree.

Ideally we'd get associated statics, but if that's impossible I can just redo this out of tree (that's what I did when AnyPrivate was private).

[reem]

Just bothered to look at TypeId's docs and it is clearly marked experimental.

If both this and TypeId are unavailable on the stable version of Rust, then neither Hyper nor Iron are going to build on 1.0. That would be pretty unfortunate, but I'd honestly take the hit over Any always using unnecessary virtual calls.

[aturon]

@reem TypeId hasn't gone through the stabilization process yet, though, and we can likely get it stable for 1.0.

As we discussed above, marking this as #[experimental] is a great move: it leaves us the freedom to change Any's implementation later, while still exposing the mechanics needed for Hyper or Iron (once we stabilize TypeId.

(BTW, we are planning to run an initial 1.0 beta cycle where the stability lints are turned on, but where you can still use unstable features on the stable channel; that will help us discover things like TypeId that people are relying on that we haven't gotten around to stabilizing yet.)

[reem]

@aturon That sounds great. I figured that TypeId would remain experimental just because it seems like such a raw tool that it wouldn't be finished yet, but certain parts of it could easily be marked stable. For instance, it would be easy to maintain backwards compatibility of TypeId::of if we also didn't stabilize TypeId::hash, since it would be impossible to inspect the result except by comparison to other TypeIds.

[aturon]

@reem But you do rely on it implementing Hash, right?

[reem]

@aturon Yes, Hash + Eq for HashMap - that doesn't necessitate the hash method, which exposes the internal representation of TypeId, to be public.

[aturon]

@reem Ah, I see: there's an inherent hash method as well.

Great, this sounds quite doable. I will make sure TypeId is on the stabilization list.

[aturon]

@reem BTW, I just posted a comment with some more details about the stabilization status and plans.