*sigh*
Unsafe code in your be dependencies does not mean the code itself is unsafe. All it means is that there is a contract you need to enforce when using it. Literally all of your Rust code is built on it. If you don't want unsafe go make code that never has side effects.
Conversation
I really am coming to the side where thinking unsafe was the wrong word choice. It gives the wrong idea as if it's something that should be avoided, rather than an inherent part of doing anything interesting with a computer. It's the guts of any abstraction.
2
8
I would have gone with ‘trusted’ for the blocks, but kept ‘unsafe’ on methods.
2
3
Same!
2
2
Very same - up until about a week ago, by when the small seed of discontent that is "but `trusted` sounds like a positive thing!" had grown from "but that's not really an issue" to "...actually, I'm not satisfied with this, and want a better option". (Took over a year.)
1
2
Of course, *we* know that the true nature of the situation is that normal code doesn't *need* for us to trust it, because the compiler is able to vouch for it, and only code that uses `unsafe` things does, and that `trusted` is how we say that we do.
1
But all that's not evident from the name and it should be.
What the name should emphasize is what the difference from the rest of the code actually is: that this bit *needs to be trusted*.
I haven't come up with a less awkward one than `needstrust`. :C
1
Hmm... What about `trustme`? :p
1
1
I unironically think I prefer it! Only small niggling problem this time is it's not an adjective(-y thing).
1
1
If there's anything I've learned about computers, naming things properly is very hard
1