Open joshtriplett opened 2 hours ago
@rfcbot merge
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. See this document for info about what commands tagged team members can give me.
I don't have a strong preference on defaulting to safe vs making you pick safe vs unsafe. If we add safe blocks later in an upcoming edition we can always require explicitness in the same edition.
I like the idea of avoiding an extra set of braces.
@rfcbot reviewed
@rfcbot reviewed
This makes sense to me.
The ability to have safe blocks makes sense for folks building control-flow abstractions on top of inline-assembly. I am indifferent about whether or not it is the default, but if there is to be a default, I prefer safe ("fails open", as Josh said).
@rfcbot reviewed
:bell: This is now entering its final comment period, as per the review above. :bell:
asm
goto requires labeled blocks, likeasm!("...", foo = label { code() });
.We need to decide whether those labeled blocks are safe by default or whether they require explicitly writing
safe
orunsafe
. I'm filing this issue for T-lang to decide which of those we want to go with.Based on discussion with the Rust for Linux folks, I'm going to propose that these blocks should default to safe, and require an explicit
unsafe
if you want them to be unsafe.I'm also going to propose that you shouldn't need nested braces if you want unsafe here:
label unsafe { dangerous_code() }
should work, rather than having to writelabel { unsafe { dangerous_code() } }
.