Unnecessary cloning in `Model` and `MapModel` (Rust) about slint

[ogoffart]

Thanks for the issue.
I'm afraid we can't avoid the clone here.
The model needs interior mutability because it is shared between the Slint engine and the application.
Types exposed to Slint are supposed to be fairly cheap to clone anyway.
So i'm going to close this issue since this is not possible.

[Enyium]

Hmm, in std, you have RefCell, which is simply documented as to be used in the correct manner, having to avoid the wrong overlaps of Ref and RefMut instances from a single RefCell. Otherwise, you get panics. Why insist on this kind of atomic operations by cloning the data? As far as I can see, users could be provided short-lived helper types like Ref/RefMut, during which the Slint API must not be used in an overboarding way. To encourage not doing much else and drop the helper type early, you may be able to use the approach, "Let me run your closure for you that gives you brief access."

I must say, it's strange to have a MapModel map closure that you just can't stop from cloning Strings, even though you'd simply need short access to the data.

Perhaps, it would, e.g., become a problem, if struct instances in a model contained another model, and accessing the inner model during a MapModel map closure could cause a panic. But could this simply be handled with good documentation and advice to clone yourself and drop the helper type early, if need be? Of course, panic messages would also need to give you proper hints.

[ogoffart]

That's why you should use SharedString instead of String so that cloning doesn't allocate.
We can't expose Ref because we don't know what is the exact underlying method used for interior mutability. Could be a Mutex or something else.

[Enyium]

I wasn't talking about exposing Ref/RefMut, but providing similar small helper types (like I talked about a MutTracker in the other issue). An implementor of Model wouldn't be forced to use RefCell to provide this method:

// Lifetimes could be left out in practice, as far as I can see.
fn row_data<'a>(&'a self, row: usize) -> Option<ReadonlyHelperType<'a, Self::Data>>;

ReadonlyHelperType (not the final name) could even be a generic type parameter on Model that a Model implementor would make concrete by specifiying either their own implementation of an associated helper type trait, or by using the Slint API's helper type trait implementation that's suited for usage with RefCell.

---

SharedString is not as sophisticated a type as String and shouldn't grow rampant into the backend. If you have a String in the backend from wherever and want to map it to a StandardListViewItem, which includes a SharedString, by surrounding the text with more text, you have to allocate a SharedString; but MapModel first gives you a clone of the original String, which is not in the spirit of std. The next owned instance created should be derived from a reference to the data.