After just writing a bunch of 'cast: gcsafe' the idea of a 'safe' annotation would get annoying very quickly if it bubbled up. Nim libraries reuse of C libraries quite often. If Nim were to adopt something of Rust's style I'd prefer a block annotation that'd enable cast/addr but not propagate an effect. The only reason would be to enforce a easy-to-grep-for marker that some code needs extra attention.
Overall I find Nim's style much more approachable than Rust's. With a tiny bit of discipline and a few unit tests it's easy enough to wrap C libraries into safe Nim API's that'll be pretty much equal to Rust's safety in wrapping C code. Also, I've come to appreciate the idea of gradual improvement. It seems it'd be possible to write static analyzers for Nim code that could let you check whatever set of properties you wanted to, possibly by custom tags. Then a team can start out with quick-and-dirty code and gradually tighten restrictions as needed/desired. Making that ability first class would provide more payoff for the effort required than safe/unsafe blocks. Though I will admit I've had a few more null pointer exceptions than I'd prefer in plain Nim code. If there's any big "unsafety" issue in Nim compared to Rust it's how easy it is to forget to initialize a 'ref variable'. It doesn't lead to buffer overflows so I don't think it's a security issue. More that it's annoying how often I refactor a piece of code and forget to initialize a ref variable or sequence.
