I think it may be valuable to have a better understanding of how cross-language unwinding is understood by other language communities and how the designers of those languages expect it to work. This would help us see perspectives on the issue we might otherwise miss and could even have the more concrete benefit of informing design design decisions that would facilitate interop not just with C but with more modern systems languages.
I've actually already had a few discussions along these lines, but more outreach might be good.
Conversations I've started already, organized by language:
- C++ (and D)
- Nick Lewycky: previously worked on LLVM for several years and is now working on Wasmer, which (from the outside) looks somewhat like Lucet. I've quoted him a few times in this project-group, e.g. "FFI is not a sandbox." I've emailed him about this group, but I don't know if he will be interested in participating at all.
- Herb Sutter: chair of the C++ ISO committee member; I believe he also leads development of MSVC or did at one point. I emailed him some specific questions while working on the old RFCs, but I haven't emailed him again since the project group was formed. He told me about the cross-language error-handling proposal in the works for C and C++.
- Andrei Alexandrescu: another well-known C++ expert who currently works full-time on D. My first email to Mr Sutter was also addressed to Mr Alexandrescu, but I did not receive a response.
- Andrew Kelley: author of Zig. Zig seems to me like a viable candidate to fully _replace_ C on future platforms; and in fact this can happen incrementally, because I learned the other day that when linking Zig programs against C code, Zig actually _compiles_ the C code rather than relying on a shared object. Andrew said he would be interested in discussing unwinding with us, but won't have time for about two weeks.
Some other languages that might provide good perspectives, and why they would be interesting to us specifically:
- Go: feature-minimalism, "medium weight" runtime (not a VM, but also not "bare metal")
- Ada: focus on safety
- Pony: capabilities-secure design, but with C FFI. Outside of FFI, "all exceptions have defined semantics, and they are always handled." I think this is the most Rust-like set of design constraints of all the languages listed, and it would be good to know if the designers intend to "protect" Pony code from foreign exceptions in some way.