[asdf-asdf-asdf]

i don't think i missed the point here.

i wrote: "i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes."

you wrote: "Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down."

it's the same thing. the difference is that you look at it from the glass-half-full point of view (it's good that must-be-verified-by-a-person blocks are limited here), and i do from the other end (it's bad that these blocks are necessary).

[nickez]

I think you missed parent's point. There are constructs that the current compiler can't prove is correct and to write such code you need unsafe. It is often not about a trade-off between speed/safety.

[Jonhoo]

I actually gave a talk about exactly this a few weeks back that may be relevant: https://youtube.com/watch?v=QAz-maaH0KM

[asdf-asdf-asdf]

oh, i see what you mean. yes, i did somehow miss the "You can't build everything in safe Rust - certain things _require_ the use of unsafe." part of the argument.

i did talk about it in my other comment here: https://news.ycombinator.com/item?id=22701550

[leshow]

You obviously don't understand, unsafe isn't always optional. You literally can't do some things without it. If you tried to build a Vec from scratch without unsafe for example (or using code that uses unsafe) you would fail.

Data structures are a perfect place for judicious use of unsafe.