Miss Dada  🏳️‍⚧️

but the compiler doesn't *force* you to mark a function that contains `unsafe { ... }` as `unsafe`, you have to elect to do that? so `unsafe { ... }` is you going "look, I know rustc can't prove this memory use is ok, but trust me I know what I'm doing"

correct. unsafe { } means within this block of code I have upheld the invariant. whereas marking the fn unsafe means, you the callee need to uphold some invariant.

does "invariant" here only include invariants the borrow checker can prove, or any invariant at all? would one ever mark a fn unsafe if it didn't contain anything that would require an unsafe block (i.e. raw ptr deref etc)

like, I could write a broken impl of some data structure in safe rust, but marking its API unsafe wouldn't fix that

Right, `unsafe` is very specifically about memory safety and undefined behavior

though I do wish there was some way that wasn't `unsafe` to say hey like if you use the API this way you might have a bad time if you don't do x, y, and z

I would simply not write APIs with this property being slightly facetious but to me a core element of object APIs is that it should not be possible to put them in a bad state by any sequence of messages

I had some weird stuff porting your git book over to rust and file locking where there were some issues around ownership or whatever. Can't remember the exact reason. While I had to make an escape hatch in the API to get it to work I wasn't happy about it. Not sure what the cause