Better TypeId

[oscartbeaumont]

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 'static TypeId without them
• or remove NamedType::SID which I could see happening.

[oscartbeaumont]

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.

[indietyp]

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 (bevyengine/bevy#32). The note in the type_name is quite important here: https://doc.rust-lang.org/std/any/fn.type_name.html

[oscartbeaumont]

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.

[oscartbeaumont]

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.