-
Notifications
You must be signed in to change notification settings - Fork 13.3k
TRPL states that unsafe occurs in two locations #26345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Note that Send and Sync are the only two stable unsafe traits, but there are more in the unstable pipeline. |
Is |
To my knowledge. We used to have |
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this issue
Jul 7, 2015
I am not mentioning #[unsafe_drop_flag] because it should go away eventually, and also because it's just an attribute, it's not really a use of the `unsafe` keyword. Fixes rust-lang#26345
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this issue
Jul 7, 2015
I am not mentioning #[unsafe_drop_flag] because it should go away eventually, and also because it's just an attribute, it's not really a use of the `unsafe` keyword. Fixes rust-lang#26345
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the unsafe section:
It occurs in 4-5 depending on how you count:
#[unsafe_no_drop_flag]
In my TURPL draft I currently state the following:
Their are several places
unsafe
can appear in Rust today, which can largely begrouped into two categories:
you to write
unsafe
elsewhere:unsafe
is declaring the function to be unsafe to call. Usersof the function must check the documentation to determine what this means,
and then have to write
unsafe
somewhere to identify that they're aware ofthe danger.
unsafe
is declaring that implementing the traitis an unsafe operation, as it has contracts that other unsafe code is free to
trust blindly.
unchecked contracts:
unsafe
is declaring that the contract of theunsafe
trait has been upheld.unsafe
is declaring any unsafety from an unsafeoperation to be handled, and therefore the parent function is safe.
There is also
#[unsafe_no_drop_flag]
, which is a special case that exists forhistorical reasons and is in the process of being phased out. See the section on
destructors for details.
The text was updated successfully, but these errors were encountered: