Serde Serializer/Deserializer for Lua Value about rlua HOT 4 CLOSED

Agreed. Implemented in separate crate - https://github.com/zrkn/rlua_serde/
Thanks for feedback, I think we can close this.

from rlua.

I've definitely had the same idea, it's cool that you implemented this and I'll definitely take a look at it.

The problem with doing this though, is that it creates two paths for serialization, the Serialize / Deserialize path and the ToLua / FromLua path.

If there a way that we could provide some sort of to_lua_serialize! and from_lua_deserialize macros that make a struct that is Serialize / Deserialize implement ToLua / FromLua, that would be really interesting. I haven't looked into it, but I don't think that's possible to do in a way where it forwards to ToLua / FromLua on the fields of the struct implementing Serialize / Deserialize, and if you have two separate serialization systems, I don't think that's going to work out very well.

The problem is something like this, suppose you have a struct Complicated with a bespoke impl ToLua for Complicated and impl FromLua for Complicated. Then, if you have a #[derive(Serialize, Deserialize)] struct Compound { complicated: Complicated }, at best using Serialize / Deserialize to do the Lua conversion won't compile, but at worst it may actually use a serialization that you don't actually want. I don't really want there to be multiple parallel ways to do Lua serialization.

I might be wrong though, and that might be feasible to forward to ToLua / FromLua using the Serialize / Deserialize traits, and if so that might be a viable strategy to try?

from rlua.

There is a difference between ToLua/FromLua conversion path and Serialize/Deserialize, which can be a reason to keep them separate. ToLua/FromLua consumes self, when Serialize/Deserialize takes it by reference. Basically, first is conversion and second is serialization which are a bit different operations. End user can choose which is more appropriate for them.

from rlua.

Hmm, you're right, it's not really possible to combine them.

I'm not sure having that functionality in this crate is the right choice, would it be possible to have Serialize / Deserialize based Lua conversion as an external crate? Maybe you could have an extension trait on Lua that adds pack_serde and unpack_serde?

On a side note, I would eventually like to have some kind of ToLua / FromLua derive procedural macro.

from rlua.