specta-rs
Better `TypeId`
Hack around the 'static bound on Rust's built-in TypeId to allow the ID to be tied to a compiler intrinsic instead of the implementation location of the macro like it currently issues.
Issues blocking merge:
- Lack of const traits or a workaround a non
'staticTypeIdwithout them - or remove
NamedType::SIDwhich I could see happening.
SomeGenericType<A> and SomeGenericType<B> will have a different TypeID which from a Rust language perspective makes sense but Specta can't work with that so this probally isn't going to be possible.
How about something like: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d0c96326c80dbadb1cd688a570040b03 ?
The idea comes from an issue I read on StableTypeId in bevy (https://github.com/bevyengine/bevy/issues/32). The note in the type_name is quite important here: https://doc.rust-lang.org/std/any/fn.type_name.html
I considered it but I don't think it's a good idea.
The returned string must not be considered to be a unique identifier of a type as multiple types may map to the same type name.
Taken from the Rust docs for type_name.
fyi, different versions of a single crate can be included in a dependency tree, so even without plugin loading I believe you can have multiple types with the same type_name but different layouts :/
From here
I would suspect this would be a problem. Rust also reserve the right to change the output of type_name so I don't love the idea of relying on it so crucially.
The more I think about it I suspect the current implementation of SpectaID would break if you have multiple of the same crate, however, that's an easy fix so I still see it as a problem.