Figure out how to get rid of 'unsafe'.

[floooh]

The examples have quite a few unsafe in them. Would be nice if the sokol-bindings would allow to write code without usafe.

Maybe having separate internal C-compatible structs and public 'Rust-y' structs like I mentioned here (#6) could be the solution?

[EriKWDev]

Yes, there are some places where unsafe is needed currently.

The main one is whenever you want to convert a C-style pointer into a rust reference, we need to dereference it which in rust is unsafe for C pointers since they "could be null".

This includes *const sapp::EventType, *mut core::ffi::c_void userdata for all callbacks.

One thing I thogh about was making all the userdata related functions that return a *mut core::ffi::c_void instead be generic over a type T and return a mutable reference to that T.

This could look as such:

fn userdata<T>() -> &mut T {
    unsafe { std::mem::transmute(ffi::userdata() as *mut T) }
}


// At call-site no unsafe needed, just explicit type required 

let state: &mut MyStateStruct = sapp::userdata();

I'll have to think about if that transmute is valid. I'm not at a computer atm but I believe if we simply dereference the pointer and cast it normally to a reference we will get lifetime issues when we return it, but that might be incorrect.

The other places where unsafe is used are where I chose to use a global variable for the state instead of passing it as userdata. Getting a mutable reference to global data in Rust is considered unsafe always and is not related to the sokol bindings.

[floooh]

As a reminder, see comments here:

#26

...and here:

#30

...maybe the fix to avoid global state (and instead pass heap-allocated state into callbacks via the user_data pointer) can be wrapped in some sort of SokolApp helper "class" which contains the "unsafety".