Dynamic type ids

[Fidius-jko]

I created example code for dynamic type id.

trait GTypeId {
    fn set(id: u32);
    fn get() -> u32;
    fn is_setted() -> bool;
}

// GENERATED BY DERIVE MACROS
mod ___DERIVE_GEN_PROTECT_B___ {
    use super::B;
    use crate::GTypeId;

    static mut TYPE_ID: u32 = 123457852; // For example
    static mut IS_SETTED: bool = false;
    impl GTypeId for B {
        fn set(id: u32) {
            unsafe {
                if IS_SETTED != true {
                    TYPE_ID = id;
                    IS_SETTED = true;
                }
            }
        }
        fn get() -> u32 {
            return unsafe {
                if IS_SETTED == false {
                    panic!("Trying get non setted GTypeId")
                }
                TYPE_ID
            };
        }
        fn is_setted() -> bool {
            return unsafe {
                IS_SETTED
            };
        }
    }
}
// END 
struct B;

// ...
pub mod type_ids {
    use std::sync::Mutex;

    use crate::GTypeId;

    static IdsCounter: Mutex<u32> = Mutex::new(0);
    pub fn init_id<T: GTypeId>() {
        if !T::is_setted() {
            let mut counter = IdsCounter.lock().unwrap();
            T::set(*counter);
            *counter += 1;
        }
    }
}
// ...
fn main() {
    type_ids::init_id::<B>(); 
    // .... Using B id for example B::get()
}

I do this because We have problem with dynamic libs because they can have similar type ids
What do you think?

[SkiFire13]

This won't work for generic types since any instantiation of that type will get the same id even though they're different (e.g. Vec<u32> and Vec<String>).

Your implementation is also not thread safe. In general please avoid using static mut as it is being deprecated. This usecase is simple enough that an Atomic type will do just fine and will be completly safe.

That said, what exactly is your problem with type ids in dynamic libs? Do you have some example?

[Fidius-jko]

For example, there is a custom mod that is written in Rust. And mod creates its own components. In theory, when we compile a mod, the compiler does not know that the game has types with similar identifiers. And he can give the mod type the same identifier as the type that is in the game.
And then, when requesting a component, you can get another component but with the same identifier and when converting types you will get an error

[SkiFire13]

Type ids are computed using a hash function based on the crate containing the type and its definition, so using a dynamic library (or changing anything in the crate that can affect the type) will almost surely make it different.