Stable type identifiers

You've asserted that stable type names (or some form of identifier) is desirable, but as far as I can tell, you've failed to identify why. What exactly are the use cases, why do they only care about type identity and not structure/ABI, and why aren't they served by existing solutions?

People have identified potential flaws in the initial idea, but without semi-concrete use cases that we can evaluate the solution against, it's difficult for anyone to identify whether those are blocking or a non-issue (or even a desirable limitation).

The closest to a concrete application I was able to determine[1] was for (de)serialization, especially in a bevy ECS like serialized List<dyn Any> scenario.

For typical serde-like serialization schemes, the type name alone is enough (or even more than enough), as type context informs what the possibilities are. It doesn't matter if Left is ambiguous, because in the context of deserializing the specific container type you already know it must be Either::<T, U>::Left. This is what allows highly contextual an non-self-describing binary formats to work at all.

In the case of a heterogenous collection, things get more complicated, which is why serde can't support deserializing dyn Trait out of the box. What can be done is collecting a list of every impl Trait that you potentially care about[2], and then essentially deserializing a fake enum Everything with variants for every implementor.

Bevy very specifically wants legible names for their textual scene format, so 128bit or 256bit hashes are not a great option for them. For formats that aren't meant to be human readable, though, an opaque but stable type identifier would mean this strategy won't run into name collisions! ...Except you still need to deal with renames, potentially even cross-crate renames[3], and you need to annotate/register your types somewhere, so you might as well assign a #[track_caller] Location[4] based identity by default and allow specifying a user defined id for cases that need stability in the face of Location changing refactora.

1. "For plugins" isn't very specific, and any usages I can come up with don't need name stability between versions without also needing ABI compatibility info or just simplifying to the (de) serialization case. ↩︎

2. Either via explicit registration like bevy-reflect, or implicitly like typetag. ↩︎

3. E.g. extracting a type into a lib-core crate so it's still the same type between lib@1 and lib@2. ↩︎

4. It's not currently possible to construct Location except via the panic machinery. I'd be weakly in support of extending that capability to user code alongside appropriate warnings about stability and appropriate usage like exists on any::type_name and other for-debug-usage APIs. ↩︎