That sounds like we actually mostly agree on this stuff, and the disagreement is mostly a matter of tone and emphasis.
In particular, where you say “demonize” in your post, I’d say “the bar for declaring a piece of unsafe code “known-sound” should be extremely high”. That’s obviously very different from and not at all in conflict with my “don’t demonize” meaning “don’t discourage library authors from using known-sound unsafe code”.
(again, if anyone can think of better slogans/shorthands, I’m all ears)
As a quasi-conclusion: I would think it falls under the purview of the security working group’s efforts to audit and minimize
unsafe throughout the ecosystem to also decide:
- exactly where we should set the bar for declaring unsafe code to be “known-sound” (e.g. a test suite with some amazing coverage metrics that fully passes the stacked borrows model)
- if there are any
unsafes where a
no-unsafefeature would be appropriate for whatever reason (e.g. its soundness depends on unresolved issues with the unsafe code guidelines, so it’s impossible to prove sound or unsound for now)
Unless someone has a concrete example they’d like to dig into, I think we’ve probably exhausted the philosophical discussion for now.