Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/ref

Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/reference type, don't have any run-time overhead. By their nature, as long as they exist, so does their target. You don't need a sophisticated borrow checker to ensure it. "Mut" (i.e. retargetable) references, on the other hand, do require a borrow checker to ensure, at compile-time, that their target will outlive them. Since SaferCPlusPlus does not have a borrow checker (yet), you'd have to use "registered" pointers, which do have run-time overhead. But in practice, retargetable references are generally much less common than non-retargetable ones (particularly in inner loops), so there tends not to be much effect on performance. SaferCPlusPlus does not yet have an exact analogy to Send/Sync. But as I understand it, those are basically just indicators that say "Trust me, this object is safe to send to / share with other threads." without any verification of the proclaimed safety. At the moment, SaferCPlusPlus does something functionally similar by providing the "TAsyncSharedObjectThatYouAreSureHasNoUnprotectedMutablesReadWriteAccessRequester" which basically allows you to make the same claim about the safe shareability of the object. (And has an unwieldy name to remind you of the seriousness of the claim.) Basically the rule of thumb is "Don't share any object that contains pointers/references/iterators (or is declared "mutable" in C++) or has any (non-static) member functions that return pointers/references/iterators." Rust and SaferCPlusPlus maybe take different positions on whether sharing objects between threads should be encouraged with abandon, or done prudently and only as necessary.