Open zeenix opened 2 years ago
Thanks for reporting this. I think it'd be indeed better if we didn't replace the trait but rather implemented it. At least that's what we should try first and if (for any reason) it doesn't work, we can document it better.
We're pretty short on developer time these days so if you could give it a shot, that would help in making this happen sooner.
Adding "API break" tag cause keeping the source trait around could easily conflict with other symbols in the module (e.g the trait impl via dbus_interface
macro).
In GitLab by @grodin on Dec 6, 2021, 23:46
It wasn't clear that when you write
that the struct that is generated for you has all the functions and methods of the trait, but doesn't actually implement it, and in fact effectively replaces it.
It was confusing the heck out of me that I couldn't write a function
without the compiler complaining that the trait wasn't in scope. It was only after I used
cargo-expand
to check what was actually generated that it became clear that the scope was "replaced" by the struct.It would be great if the generated struct actually did implement the trait, and the trait remained, but not knowing much about macros, I've no idea if this is possible.