Viability of C ABI bindings

[philpax]

Hi there!

I asked this in the Discord, but realised I should commit it to a less-transient form. Just paraphrasing the discussion I had there:

If I'm willing to forgo the safety guarantees of the egui API, is it possible to wrap egui with a C ABI / something similar? I'm thinking about exposing egui to a scripting language / wasm and am wondering how viable that is, or if there's anything particularly Rusty that might pose issues.

It should be possible to provide C ABI functions that provide an embeddable interface to the scripting language while transparently translating everything to egui-rs calls behind the scenes. A similar solution is already necessary for imgui - cimgui is used by all of the other language wrappers (like imgui.net) as there's no stable C++ ABI - but I don't know if there's anything particularly prohibitive about doing the same with Rust (e.g. lifetime/ownership-dependent idioms). Of course, writing the wrappers would suck, but it is what it is 😆

Here's a rough sketch of what the README example would look like if written with a C ABI wrapper accessed from C++:

egui_ui_heading(ui, "My egui Application");
egui_ui_horizontal(ui, (void*)&std::make_tuple(ui, name), [](void* userdata) {
    auto [ui, name] = *(std::tuple<egui_ui*, egui_string*>*)userdata;
    egui_ui_label(ui, "Your name: ");
    egui_ui_text_edit_singleline(ui, &name);
});
egui_slider* slider = egui_slider_new(&age, 0, 120);
egui_slider_text(slider, "age");
egui_ui_add(slider);
if (egui_button_clicked(egui_ui_button(ui, "Click each year"))) {
    age += 1;
}
egui_ui_label(ui, fmt::format("Hello '{}', age {}", name, age).c_str());

This would, of course, be nowhere near as safe as the original API, but for my use-case I'd be rebuilding bindings on top in a higher-level language that can enforce that safety. (or coming up with something crazy like replacing egui's implementation with calls to the C ABI, so that you can compile it to wasm and enjoy both the interface + native implementation)

[emilk]

This would be very cool imho, and there is similar discussion in #1004