RFC: Add safe blocks #3768
RFC: Add safe blocks #3768
Conversation
text/3768-safe-blocks.md
Outdated
| # Reference-level explanation | ||
| [reference-level-explanation]: #reference-level-explanation | ||
|
|
||
| I'm not super familar with the internals of rustc, but the parts that would need to be modified are probably mostly the parts involving unsafe blocks. This would directly impact those parts because of the nature of the feature. As mentioned in the summary, this also adds a lint(I don't have any ideas for the name right now; please let me know any ideas) that would trigger upon the anti-pattern of `unsafe { safe { /* code */ } }`(or vice versa of course). I'll try to provide details about how it would be implemented, but I don't know how unsafe blocks are implemented to begin with, however based on the messages it appears as though this would be implemented in the AST passes section of rustc(let me know if this is completely incorrect or if I stated this incorrectly). |
There was a problem hiding this comment.
the general idea of the reference-level explanation is that, rather than describing how it should be implemented in rustc, you instead describe exactly how the syntax works since the idea is this section of the RFC gets copied to the Rust Reference, you could adapt the text from the reference section on unsafe blocks
There was a problem hiding this comment.
Ohh, thank you! I'll fix that now. Should I keep my paragraph on rustc or no?
|
As a (not very good) prior art there were the push_unsafe!({
expr_1;
pop_unsafe!({
expr_2;
})
})
// similar to this RFC's
unsafe {
expr_1;
safe {
expr_2;
}
}It is a very ugly hack and the surface syntax is quickly removed in 1.5.0 (rust-lang/rust#28980), but the remnants are only purged 6 years later in 1.55.0 (rust-lang/rust#85421). As for the RFC itself
|
|
if if there's enough code that conflicts, |
|
Every single motivating example can be solved better by reducing the overly large scope of the |
First of all, The reason If this RFC has to use the syntax |
|
I'd think some localized flavor of Could |
|
Hmm, yes, Perhaps the |
I disagree for 2 reasons:
|
| # Rationale and alternatives | ||
| [rationale-and-alternatives]: #rationale-and-alternatives | ||
|
|
||
| This design fits in nicely with unsafe blocks and how they look/are implemented. This is a matter of preference, however and there are alternatives. Using the incrementing example, you could do this: | ||
| ```rust | ||
| macro_rules! inc { | ||
| ($a:expr) => { | ||
| let mut a: u64 = $a; | ||
| unsafe { | ||
| asm!("inc {}", inlateout(reg) a); | ||
| a | ||
| } | ||
| }; | ||
| } | ||
| ``` | ||
| However, this decreases readability in my opinion, however this is a matter of opinion. This design also seems the most natural when you are learning rust as it is very similar to unsafe blocks. If this isn't done, there isn't much direct impact, however it does decrease readability in certain circumstances. As far as I know, this couldn't be implemented in a macro, but I could be wrong. As mentioned, this generally increases readability. |
There was a problem hiding this comment.
Another alternative worth mentioning that I think would serve the same purpose: allowing finer-grained control of where unsafe is applied (e.g. though single function call unsafe), such that you won't need a safe block anymore.
Which one is better is a matter of preference. I personally like having only one unsafe operation per unsafe block, so I can explicitly document on the block why the preconditions are met, so I'd prefer having finer-grained unsafe blocks, but I know other people like to include the entire code incorporating a safety invariant in one unsafe block that details the invariant requirements. And nothing prevents Rust from having both, though the second one would have diminishing marginal returns.
I'm not the arbiter of which approach Rust should take, but I think it'd be worth mentioning in the alternatives section, at least.
So use |
|
Overall, I don't get the feeling that this proposal justifies the added complexity of having a whole new keyword and mechanism in the language. First, as tczajka said, all the motivating examples have un-idiomatically broad Second, this feels like the kind of thing where the main place that it'd be relevant is when a macro is subverting how (I'm reminded of what a brain-bender it was to realize that, though there was no trait for me to implement to extend Keats/validator in the way I wanted, I could extend it just by defining my own extension trait because it being written using macros meant that |
This RFC is a proposal for so-called "safe blocks" that would provide the opposite effect of unsafe blocks.
Rendered