When is it appropriate to mark a trait as unsafe, as opposed to marking all the functions in the trait as unsafe?
A function is marked unsafe
to indicate that it is possible to violate memory safety by calling it. A trait is marked unsafe
to indicate that it is possible to violate memory safety by implementing it at all. This is commonly because the trait has invariants that other unsafe code relies on being upheld, and that these invariants cannot be expressed any other way.
In the case of Searcher
, the methods themselves should be safe to call. That is, users should not have to worry about whether or not they're using a Searcher
correctly; the interface contract says all calls are safe. There's nothing you can do that will cause the methods to violate memory safety.
However, unsafe code will be calling the methods of a Searcher
, and such unsafe code will be relying on a given Searcher
implementation to return offsets that are on valid UTF-8 code point boundaries. If this assumption is violated, then the unsafe code could end up causing a memory safety violation itself.
To put it another way: the correctness of unsafe code using Searcher
s depends on every single Searcher
implementation also being correct. Or: implementing this trait incorrectly allows for safe code to induce a memory safety violation is unrelated unsafe
code.
So why not just mark the methods unsafe
? Because they aren't unsafe at all! They don't do anything that could violate memory safety in and of themselves. next_match
just scans for and returns an Option<(usize, usize)>
. The danger only exists when unsafe code assumes that these usize
s are valid indices into the string being searched.
So why not just check the result? Because that'd be slower. The searching code wants to be fast, which means it wants to avoid redundant checks. But those checks can't be expressed in the Searcher
interface... so instead, the whole trait is flagged as unsafe
to warn anyone implementing it that there are extra conditions not stated or enforced in the code that must be respected.
There's also Send
and Sync
: implementing those when you shouldn't violates the expectations of (among other things) code that has to deal with threads. The code that lets you create threads is safe, but only so long as Send
and Sync
are only implemented on types for which they're appropriate.