Zeeshan Ali Khan

@yoshuawuyts Hey, do you think you'll be getting around to implementing this? If not, please close it as I won't have the time or motivation for this.

> don't know, do you think it would make sense to be part of this library? TBH, I don't have any strong opinions either way but if we were to...

> I was thinking we’d do it more the other way around: add the functionality to async-broadcast, then optimize it. And once that’s done we can merge it back into...

In GitLab by @Cogitri on Aug 10, 2020, 15:45 > They were able to workaround the issue using `Rc` (right?) Nope, I switched to returning an owned struct (so I...

@Cogitri Not sure I follow. You don't have to do anything extra for `Rc` and treat it just like a clone of the data.

In GitLab by @Cogitri on Aug 10, 2020, 16:42 My code is something like this: ```rust struct Database; struct Package Package { [...] } } struct DBusServer; #[dbus_interface(name = "dev.Cogitri.apkPolkit1")]...

> Wrapping Database in an `Rc` won't help here since it'll be dropped at the end of the function either way, but you clone() it, it'll be just like cloning...

In GitLab by @Cogitri on Aug 10, 2020, 22:18 Yes, but I'd have to save that cloned Rc somewhere then, otherwise both the clone and the original variable will be...

What lifetime? Actually you don't even need Rc. ```rust // Database and Package remains the same // Notice it's plural struct Packages { db: Database, } impl serde::ser::Serialize for Packages...

In GitLab by @Cogitri on Aug 10, 2020, 22:35 🤯 saving the Database in the Packages struct sure is clever, how did I not think about that :D Great, thanks...