Would you mind elaborating on what you're trying to get at with your first two sentences? What "sort of thing" are you talking about?
Also, define 'correct'. What does it mean for a `unsafe` block to be 'correct'?
My point is largely that for an `unsafe` block to be correct, it relies on other safe code to also be correct in ways the compiler can't verify. So just because your `unsafe` blocks are small and infrequent doesn't say anything about the quality or "buggyness" of your code as a whole if those `unsafe` blocks are dependent on largely the entire rest of the safe code.
> just because your `unsafe` blocks are small and infrequent doesn't say anything about the quality or "buggyness" of your code as a whole if those `unsafe` blocks are dependent on largely the entire rest of the safe code.
This is true; what I'm getting at is that you shouldn't allow your unsafe code to depend on "largely the entire rest of the safe code."
Unsafe code should be used together with the visibility system, the borrow checker, and the trait system, so that it only depends on a very small amount of code within the same file or even the same function.
Then the vast majority of the program can be written in safe code that cannot violate the invariants of the unsafe code.
Sorry for not responding sooner, but I agree with you completely that the right thing to do is not to focus on "how many" `unsafe` lines you have, but how well encapsulated they are into a module that can't be broken by outside input. And I'm glad we both see this. My "problem" is less that `unsafe` doesn't do the things I mentioned, but that whenever Rust and `unsafe` come-up there tends to be lots of people who don't understand what it is, or how it works, and I think that is a very dangerous mindset because it leads to completely pointless (and dangerous, from a safety perspective) stuff like how that paper literally measured how many lines were `unsafe` and displayed it as a percentage to prove their code was good.
With all that said, while this is a separate topic, I think that the complete lack of a spec for lots of details surrounding `unsafe` makes it still basically impossible to do correctly. I think Rust really needs some type of language spec, but it doesn't look like any work is being done on that front [0].
Also, define 'correct'. What does it mean for a `unsafe` block to be 'correct'?
My point is largely that for an `unsafe` block to be correct, it relies on other safe code to also be correct in ways the compiler can't verify. So just because your `unsafe` blocks are small and infrequent doesn't say anything about the quality or "buggyness" of your code as a whole if those `unsafe` blocks are dependent on largely the entire rest of the safe code.