Stream: project-ffi-unwind

Topic: what Rust values are best supported by the unwind choice

view this post on Zulip nikomatsakis (Mar 18 2020 at 21:18):

Here is my "current stance" -- subject to change as ever. Something we didn't quite get into when considering the various options is "what the choice says about Rust" -- or maybe, what kind of coding we would ultimately recommend. It seems to me that a strong Rust value is that:

To that end, no matter what proposal we wound up with, it seems like we would recommend that code authors:

I think that this implies to me that it might be beneficial to separate "C" and "C unwind". It means that you have to be a bit explicit when you're relying on something non-portable, but that's perhaps a good thing, and it lets us lint more effectively. It also means we can put shims that detect all non-forced-unwinding across a C boundary and abort, thus helping to detect portability hazards. We might want to limit those to debug-mode because they would make binaries somewhat bigger, though we also ought to measure that more carefully (it wasn't too hard to implement when I tried).

I think I'll try to do a longer write-up, and also experiment a bit with what I see as the strongest argument the other way, but I was curious to write this one out. =)

(I feel that the strongest argument the other way is one that speaks to Rust enabling smooth interop with native code, and the overall simplicity of the ABI story -- extern "C" means the native ABI, full stop. But this argument of course is limited by the fact that we still enable interop in both proposals, albeit with a small speedbump of using the "C unwind" ABI, and my feeling that people will ultimately be able to understand that propagating exceptions across Rust code requires you to "opt in".)

Side note that this exercise is making me really want to take a stab at writing out the values that Rust strives for.

Last updated: Jan 26 2022 at 09:02 UTC