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"
-
-
Replying to @mgattozzi
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
2 replies 0 retweets 5 likes -
Replying to @sgrif @mgattozzi
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
1 reply 0 retweets 1 like -
Replying to @mountain_ghosts @mgattozzi
It was archived, you can see for yourself. http://web.archive.org/web/20200116231317/https://github.com/actix/actix-net/issues/83 … A function should be marked `unsafe` whenever it has invariants that cannot be upheld by the compiler. Whether that is public API or not is irrelevant, requiring `unsafe` to call a function like that is critical
1 reply 0 retweets 1 like -
Replying to @sgrif @mgattozzi
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"
3 replies 0 retweets 1 like -
Replying to @mountain_ghosts @sgrif
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.
1 reply 0 retweets 1 like -
Replying to @mgattozzi @sgrif
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)
3 replies 0 retweets 1 like -
Replying to @mountain_ghosts @mgattozzi
No, this is specifically for things that the compiler cannot check. If your function is marked as unsafe and doesn't do anything unsafe inside it, that means that one of the APIs you're calling is unsound
1 reply 0 retweets 1 like -
Replying to @sgrif @mgattozzi
what does "unsound" mean here? I know "unsound" as a property of type systems, not of functions that are valid within such systems
1 reply 0 retweets 1 like -
Replying to @mountain_ghosts @mgattozzi
I mean it both in terms of type systems, but also that safe Rust must not be able to exhibit memory unsafety or undefined behavior.
2 replies 0 retweets 1 like
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html … is good reading on this subject
4:39 PM - 16 Jan 2020
0 replies
0 retweets
2 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.