Serde compatibility

[dominiwe]

First of all, cool crate and cool initiative.

I wanted to ask, is the crate compatible with mluas serde feature? For example, say I have a struct with a field name and #[serde(rename = "new_name")]. Do the generated type definitions respect that?

If not, maybe one could use serde_derive_internals (although unstable) to change that.

[Tired-Fox]

@dominiwe, thank you for great the question!

The crate does not currently support this. I don't think hooking into serde attribute macros for renaming struct fields would be beneficial with how the crate currently works.

The Typed derive macro is the only derive macro used for the types. The macro is used for Struct, to get the name of the lua "class", and for Enums, to get the name of the lua type alias along with the variants as lua strings which are set as a lua type union.

On the idea of struct fields, this crate doesn't currently support generating those from macros. They are technically generated from the Struct implementing TypedUserData which is a drop in for mlua's UserData where it will automatically tracks fields, methods, and functions. When using the struct in the code it acts as UserData, and when the struct is used with Definitions::generate it will treat the normal add_method, add_function, etc as no-op and instead reads the type information and automatically transforms it into lua type definitions.

With this in mind, the main idea of allowing the Typed macro to have the ability to rename the Struct along with the Enum and its variants is something that could be implemented. If you would like to see this I can attempt to implement a standalone attribute macro that allows for object rename along with renaming all or some of the variants. I could also implement parsing for the serde attribute macro and handle renaming based on the serde fields like rename and rename_all.

[Tired-Fox]

I would have two proposed changes:

1. Typed will gain the ability to rename the Struct along with the Enum and its variants
2. Definition would get an overhaul to support things that implement serde and automatically add fields to classes

[dominiwe]

Oh that's quite convenient, I hadn't looked at TypedUserData yet.

That makes sense. I think being able to rename the struct along with the enum and its variants or even just an escape hatch to manually write the type definition once but keep it close to the struct definition would be nice.
Though the second thing you proposed seems nice, it also seems hard to implement to me.

[Tired-Fox]

There is an escape hatch. The Typed derive macro implements the trait with the same name. It creates a mlua_extras::typed::Type::Enum with the variants listed as the value of the type. The final part of the Typed macro that generates this looks like this

quote!(
    impl mlua_extras::typed::Typed for #name {
        fn ty() -> mlua_extras::typed::Type {
            mlua_extras::typed::Type::r#enum(
                #value,
                [ #(#variants,)* ]
            )
        }
    }
)

Where #value is the name of the enum and #variants is a list of the variant names as strings.

If you are still interested in the functionality of renaming the enum and its variants with the macro then I can start work on an update.