6 ms·

Yes. The idea is to isolate the use of unsafe and prove that it is safe. Because compiler cannot prove that what you're doing is safe it is your responsibility

Yes. The idea is to isolate the use of unsafe and prove that it is safe. Because compiler cannot prove that what you're doing is safe it is your responsibility to do so. Once you've _proven_ that your unsafe code is safe, then it cannot have propagating effects in the rest of the code. A lot of people get this confused. They think unsafe means you can do whatever you want. In reality it means you'll play by the rules even if the compiler cannot verify them all. In truth it is not as hard as it sounds, we do it in C all the time.

dgb23 5y ago
Should have been called „trust_me“ instead of „unsafe“.
- masklinn 5y ago
  It’s never really going to be perfect e.g. your idea doesn’t really work with unsafe functions, which can only be called from unsafe contexts but also are an unsafe context. `unsafe` in rust really means that some of the compiler guardrails are disabled: * you can call unsafe (and extern) functions * you can dereference raw pointers (this has significant consequences such as being able to create mutable references out of thin air) * you can access or modify mutable statics * you can access `union` contents
- Someone1234 5y ago
  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...
- GuB-42 5y ago
  Yes, from the compiler point of view, that's the idea, and it is right there in the manual "Trust me, I know what I’m doing.". But the keyword "unsafe" has been used in C# for quite a while, and probably in other languages too. So by the time Rust came out, it was already a well understood concept. In the C# manual: "the execution engine works to ensure that unsafe code cannot be executed in an untrusted environment". Still that notion of trust. One problem I see with "trust_me" or maybe "trusted" is that it gives the opposite message from a user point of view. Trusted code is code the compiler should trust but that you should not trust.
  - jacquesm 5y ago
    Trust me, I know what I'm doing is exactly what every C programmer thinks when writing code.
- skocznymroczny 5y ago
  D still has some issues with the safety story, but they have three safety attributes. @system - unsafe code, may do pointer arithmetics, may call C code, @safe - safe code, not allowed to do those things, @trusted - unsafe code, verified by programmer, can be called by @safe. The main issue is that it came late in D lifetime, so until situation improves, @system is the default, because there's too much std/legacy code which still assumes @system as default. Many new projects however start with @safe as default.
deleted 5y ago
[deleted]

dgb23 5y ago

Should have been called „trust_me“ instead of „unsafe“.

masklinn 5y ago
It’s never really going to be perfect e.g. your idea doesn’t really work with unsafe functions, which can only be called from unsafe contexts but also are an unsafe context. `unsafe` in rust really means that some of the compiler guardrails are disabled: * you can call unsafe (and extern) functions * you can dereference raw pointers (this has significant consequences such as being able to create mutable references out of thin air) * you can access or modify mutable statics * you can access `union` contents
Someone1234 5y ago
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...
GuB-42 5y ago
Yes, from the compiler point of view, that's the idea, and it is right there in the manual "Trust me, I know what I’m doing.". But the keyword "unsafe" has been used in C# for quite a while, and probably in other languages too. So by the time Rust came out, it was already a well understood concept. In the C# manual: "the execution engine works to ensure that unsafe code cannot be executed in an untrusted environment". Still that notion of trust. One problem I see with "trust_me" or maybe "trusted" is that it gives the opposite message from a user point of view. Trusted code is code the compiler should trust but that you should not trust.
- jacquesm 5y ago
  Trust me, I know what I'm doing is exactly what every C programmer thinks when writing code.
skocznymroczny 5y ago
D still has some issues with the safety story, but they have three safety attributes. @system - unsafe code, may do pointer arithmetics, may call C code, @safe - safe code, not allowed to do those things, @trusted - unsafe code, verified by programmer, can be called by @safe. The main issue is that it came late in D lifetime, so until situation improves, @system is the default, because there's too much std/legacy code which still assumes @system as default. Many new projects however start with @safe as default.

deleted 5y ago

[deleted]