https://bugs.kde.org/show_bug.cgi?id=448087
--- Comment #4 from Andreas Grois <[email protected]> --- I've had a look at the linked branch. That does not only contain the fix for the mutability/aliasing issue, but functionality (replaceable objects) which I don't want/need for my use case. I've started a new branch based off current master, where I'm planning to make the following changes: o) Make every &mut self be &self instead. o) Remove RustByFunction. In an immuatable context RustByFunction is the only reasonable choice for complex (non-object) types, as one can't leak a reference out of a RefCell's borrow or Mutex' lock. Since RustByFunction anyhow only works for (non-object) complex types on master, removing that user-choice does not remove functionality (that would not get lost anyhow by the switch to immutable contexts). o) Remove mut function support, for obvious reasons. o) Make functions and list/tree item properties that return non-object complex types use a similar function signature as property getters with rust-by-function. This is again because one cannot leak references out of locks/borrows. I'm also considering to wrap the creation of rust objects (what is currently just a heap allocation) in a RefCell so it can catch aliasing violations at runtime (think: some broken C++ code calling _free() as reaction to a signal sent by the same object). That should not be necessary from a correctness standpoint (again: if I didn't misunderstand something), but it'd be a nice additional safeguard. I can't make any promises when (or even if) I will finish those changes though (it's after all a spare-time project for me, and today is the last day of my vacation...), but I aim to have a first draft (code + tests) pushed to gitlab at some point during next week. -- You are receiving this mail because: You are watching all bug changes.
