Miss Dada  🏳️‍⚧️

It's annoying because the community has gone way overboard with the "no unsafe ever" trend, and I want to be on the maintainer's side. But holy shit their reactions on the issue tracker are ridiculous

Yeah like a little unsafe here and there sure. Necessary stuff, but this maintainer is too dismissive. You'll also love to hear their commit for adding their own custom unsafe cell was merely: "add custom cell"

What's frustrating with their style is they clearly don't understand what `unsafe` *means*. "There's no issue because public API doesn't exhibit UB" no that's besides the point. This function has unchecked invariants. Mark it as unsafe and move on

was the issue here that a public function is not marked unsafe, but contained `unsafe` blocks, but doesn't guarantee the invariants those blocks rely on? I'm still really unsure what forces a function to be marked unsafe

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)