> That's not how Rust defines `unsafe`. It's open to misuse, and the > compiler will happily point out that it's not being used correctly via > the unnecessary unsafe lint. >
If that's the case, do you think there's some worth in allowing the programmer to define arbitrary generic safety types? E.g have an `#[unsafe(strings)]` attribute that can be placed on methods that break String guarantees (and placed on blocks where we wish to allow such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If something like this slide <https://www.youtube.com/watch?feature=player_detailpage&v=jVoFws7rp88#t=1664> was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities can have `#[unsafe(xss)]`. Rust does a bunch of compile time checking to achieve memory safety. It also provides a syntax extension/lint system that allows for programmers to define further compile time checks, which open up the gate for many more possible safety guarantees (instead of relying on separate static analysis tools), and not just memory safety. Perhaps we should start recognizing and leveraging that ability more :) -Manish Goregaokar
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
