Why you removed impl Rc/Arc types?

[persytry]

Why you removed impl Rc/Arc types?
Are there any alternative options?
Can you provide an example? Because I have a lot of code that uses Rc/Arc.

[khvzak]

Can you try any userdata api instead?
The main motivation to support Rc/Arc types was inability to implement UserData trait for Rc<T> because of orphan rules, but since then it was solved by providing ability to register types (mlua v0.9 support this)

If there are any problems using Lua::register_userdata_type would be nice to get more information.

[evie-calico]

As far as I can tell, register_userdata_type means that the field/method definitions are non-local to the structure they're attached to (unlike a trait). Obviously for foreign types this is necessary, but with smart pointers like Rc<T> it means that field/method definitions need to be separated from the type they're associated with, even if T is in the same crate. In addition, these definitions may potentially be duplicated (Rc<T>, Arc<T>, Rc<Option<T>>, etc), and duplicate copies may not even be in the same place if you need both impl UserData and register_userdata_type.

Hopefully I'm missing something and there's a way to work around these issues, but it seems like users have to do a lot of extra work to make up for this removal.

[khvzak]

Makes sense, I'll add back in 0.10.1 support of wrapped userdata types (probably under a feature flag).