4 ms·
A less extreme variation would be "unsafe_because "X" " where X must be a string of length at least 50. You want to do something that the compiler can't unders
by piaste 5y ago
A less extreme variation would be "unsafe_because "X" " where X must be a string of length at least 50.
You want to do something that the compiler can't understand but you know how it works? Ok, write down _why_ it works so others can know that, too.
Would it be possible to write the above as a Rust macro, and mark invocations of the ordinary "unsafe" operator as a warning / linter alert?
PS: I actually wrapped most F# unsafe (= partial) functions in our codebase in such a way. `Option.get x`, which extracts a possibly-null value and crasheswise, is deprecated and replaced by `Option.getOrFail fmt args x`, where you say why you are sure the value can't be null and provide context variables to diagnose a possible failure.
e.g.
let title =
textLines
|> List.headOrFail "We generated the line lists by subgrouping the original list %A, so we know they're non-empty" originalList
- estebank 5y agoThe style guide for most projects is to include a comment on the unsafe block's header. Clippy has a lint for unsafe fns[1], and with either changes to the Rust AST (to not discard comments) or to the acceptability of doc attributes on unsafe blocks (to allow the use a /// comment on unsafe blocks), that lint could also work for unsafe blocks. [1]: https://rust-lang.github.io/rust-clippy/master/#missing_safety_doc https://rust-lang.github.io/rust-clippy/master/#missing_safe...