#Brainstorming Rust + C# interop
Use case A
- Rust UI via WPF or Persperex
- Make it feel like XAML is Rust-native
- Put function name in WPF event handler, we stub out from that to Rust code
- Rust event handlers written with a macro that we use to write interop stubs on each side
- Can I do GUI nesting without XAML? Eg like the Zinc.rs config block, but for UI elements
- Pros:
- Super cool
- Gives Rust a native Windows UI
- Cons:
- Tough interop; event handlers will have limited ways to call back into c# without a macro or plugin to enable it
- EG:
- + Rust clrfn! { print!("Worked!"); }
Use case B
- Compiler plugin that allows direct use of CLR objects from within Rust code
- Can I intercept errors from Rust and handle them? Not possible otherwise.
- Pros:
- Super powerful
- Can run any C# code
- Cons:
- Interop still hard
- Inventing new syntax
- EG:
- Something like
- fn do_stuff() { Console.WriteLine("Hi from C#"); }
- Or maybe (note alternate line ending
- fn do_stuff() { Console.WriteLine("Hi from C#"): }
- Or could be done with a macro to create the function, a function naming convention, a magic comment, or something else
Use case C:
- Rust WinForms binding
- Wrap WinForms with Rust code
- Pros
- Known scope
- Not terribly hard
- No preconceptions to overcome (eg WPF binding to C# objects would make interop hard)
- All interop + CLR hosting can be totally hidden behind a layer of pure Rust
- Cons
- It's WinForms
- Not sexy
- EG:
- message_box.show("Words");
- (new window()).show();
- (new window()).add_element(new label("Words"));
+1 for use case B and C