3 ms·

It could, it would be accurate, but they're trying to implicitly teach this idea to "avoid these." trust_me blocks lacks that implication. It is very easy, par

It could, it would be accurate, but they're trying to implicitly teach this idea to "avoid these." trust_me blocks lacks that implication. It is very easy, particularly coming from another language, to butt heads with the language's design and then try to solve it with "trust_me" blocks. Throwing everything in unsafe feels like you're doing it wrong, and correctly so.

dgb23 5y ago
My above comment was meant to be an illustration rather than a proposal. I think calling it "unsafe" is a good design choice as you explained. The downside is: Every time this discussion comes up, someone has to explain what "unsafe" actually means. Every single tech talk ever that touches on "unsafe", pre-fixes the talk with this explanation too. A more funny idea instead of "trust_me" would be "safe_because[...]" where "..." is a rationale about the code plus your social security number and biometrics data. For any control freaks and regulators out there: If you take the above seriously and try to implement such a thing you will be burnt by the stake by cyber elves.
- 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 ago
    The 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...

dgb23 5y ago

My above comment was meant to be an illustration rather than a proposal. I think calling it "unsafe" is a good design choice as you explained. The downside is: Every time this discussion comes up, someone has to explain what "unsafe" actually means. Every single tech talk ever that touches on "unsafe", pre-fixes the talk with this explanation too. A more funny idea instead of "trust_me" would be "safe_because[...]" where "..." is a rationale about the code plus your social security number and biometrics data. For any control freaks and regulators out there: If you take the above seriously and try to implement such a thing you will be burnt by the stake by cyber elves.

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 ago
  The 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...