Would it be appropriate to broaden our charter now that we are considering
longjmp et al.?
Here's our current mission statement:
To extend the language to support unwinding that crosses FFI boundaries.
I think this should be broadened to:
To extend the language to support control-flow constructs that cross between language boundaries without causing undefined behavior.
longjmp was always part of the charter...
It's currently mentioned as "maybe in scope". The current charter has the mission statement above, followed by a bunch of bullet points that are sort of... speculative.
I think that's appropriate
I feel like my original understanding of the effort was a bit off; there was less "platform by platform wrangling" than I expected
I am debating about the new phrasing, it's somewhat broad, but perhaps reasonable
in particular I'm pondering about things like C++-to-rust exception interop, which we initially kind of ruled out of scope
I'm somewhat opposed to "major additions" in this direction, at least not without considering as part of an overall prioritization, but targeted efforts (like figuring out the interaction with
may make sense
I'd like to get concrete users involved who are requesting them, though
longjmp has concrete users
I think my top priority remains "is it possible to write code without undefined behavior, given unusual legacy APIs?"
It doesn't have to be easy or "powerful" or full-featured...just not UB.
So the reason we have "extend the language" in there is that we thought it was pretty much a certainty that we'd be making cross-language unwinding opt-in.
Similarly, for longjmp, we are leaning towards an explicit opt-in.
Those are both technically "extending the language" even though they're pretty minimal, and the language-level change isn't really the core concern.
I'm not sure how (or if) this intent of minimalism should be expressed in the charter, though.
@nikomatsakis reviving an old topic: here's a pull request with this as our new mission statement:
To extend the language to avoid undefined behavior when using control-flow constructs that cross between language boundaries.
Last updated: Jan 26 2022 at 08:34 UTC