How about 'ImmutableUesrData Trait'

[JackLiar]

UserData means the targeting Rust native type could be modified by Lua scripts.

However, there are situations one just knows the data should not be modified by any Lua script, if we have something like this:

pub trait UserData: ImmutableUserData {}

then one could automatically derive ImmutableUserData to Arc<T> and save lots of redundant codes. We could move all the api that accept &T as parameter into ImmutableUserData, so UserData could handle add_field_method_get like before.

For example

use mlua::{UserData, UserDataFields, UserDataMethods};

struct Data {
    id: String,
}

impl UserData for Data {
    fn add_fields<'lua, F: UserDataFields<'lua, Self>>(fields: &mut F) {
        fields.add_field_method_get("id", |_, this| Ok(this.id.clone()));
    }
}

struct ImmutableData(Arc<Data>);

impl UserData for data {
    fn add_fields<'lua, F: UserDataFields<'lua, Self>>(fields: &mut F) {
        fields.add_field_method_get("id", |_, this| Ok(this.0.id.clone()));
    }
}

Now we have to write code like this to let Arc<Data> have the same fields and method like Data do, if we have ImmutableUserData, this is accomplished automatically.

---

Although I also know there may be other problems, I'm not a Lua expert, I may have wrong opinions.

Since Lua script is not controllable, one may try to modify the actual ImmutableUserData, and may cause undesirable issues? This is a concern for me.

[khvzak]

It's quite easy to support (in mlua) Arc<T> and Rc<T> for T: UserData on the same way how it's aready done for Arc<Mutex<T>> and Rc<RefCell<T>>. (in was in my TODO list)
If you try to modify it then Rust generate an exception.