4 ms·
Of course. And once the basics are in place (again, they're getting there but not yet), why wouldn't that ecosystem develop of it?
by raphlinus 6y ago
Of course. And once the basics are in place (again, they're getting there but not yet), why wouldn't that ecosystem develop of it?
- pjmlp 6y agoFor sure, it depends pretty much how the framework will look like. I still can't think of a way to make borrow checker deal with a GUI designer and drag and drop of components(which should be able to be plugged anywhere on the visual tree), or even something like SwiftUI, without forcing Rc<RefCell<>> everywhere. I am looking forward how Rust/WinRT will look like with WinUI, but again, COM means AddRef/Release everywhere.
- andrekandre 6y ago> something like SwiftUI one thing im having a hard time wrapping my mind around is, if swiftui depends on (please correct me if im wrong) the swift compiler itself and emited static type information from that compiler, how can rust build an interface to that easily? it seems like you'd have to make some kind of wrapper lib that emits extern c interfaces that take and return `AnyView` and thereby hurting performance...?
- pjmlp 6y agoBy having macros that produce the required information, similar to how Qt, wxWidgets do it, and Rust/WinRT is in the process of doing. https://github.com/microsoft/winrt-rs https://github.com/microsoft/winrt-rs But that is the easy part, the hard part is having the ability to plug a widget anywhere on the tree without triggering a bunch of lifetime errors. WinRT gets around this because it is built on COM, so you get reference counting no matter what.
- andrekandre 6y agointeresting... though since winrt is c/c++ based its probably easier for rust to interface with, guessing... but afaik with swift there is static type information encoded at the binary level that swiftui (e.g `some View`) utilizes to do type-based tree diffing, so i wondered how rust can generate that, even with macros... maybe im mistaken though! (thanks for the reply btw)