-
-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usage of TypeId to store type "references". #126
Comments
This could be extended to also store references to rust functions. |
Could you please explain more? What did you mean under "user type references" and serialization of them? There are few places where
If talk about |
Forgive me, I probably should have explained in more detail. However, how would Lua serialize pointers to external objects? What you must provide also provide when serializing is a 'perms' table onto the stack. Now given the various layers of safety abstraction, it may get a little more complicated to ensure that a developer using this writes their code in such a way that they can easily re-create external data, and remap to external functions when deserializing their Lua instance - so it may be better to implement this in a lower-level library. So yes, the issue with TypeID is that if a developer were to distribute a new release, it is very possible that it will break the end user's serialized Lua instances. |
But even if something else than a TypeID was used, if you have a state that uses version X for a library and then use this state in an environment where version Y of said library is used can produce very big problems if the types changed. It wouldn't even surprise me that the fact that Rust has no stable ABI on its own can already mess things up for you in a big way. And even if the types stay compatible in layout, the exact meaning of each field may have changed drastically causing invalid states anyway. if such a feature is something that you would like to see supported then I think it would require much more than just a change in how mlua tracks which types are what, if nothing else it requires some change to make developers aware of this feature existing and writing types in such a way that they can handle being fed old versions of their types. |
TypeID id's are not stable, as it is still not reliably collision resistant, and the hash generated is expected to change between Rust versions: rust#77125.
This makes it a poor candidate for serialization of user type references that is expected to survive longer-term storage.
It may be better if we want a longer-term hardened solution may be to utilize the typetag or inventory crates to allow simple serializable type references.
The text was updated successfully, but these errors were encountered: