-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Adding unsafe modules and unsafe blocks outside functions. #2148
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,84 @@ | ||
- Feature Name: unsafe_modules | ||
- Start Date: 2017-09-12 | ||
- RFC PR: (leave this empty) | ||
- Rust Issue: (leave this empty) | ||
|
||
# Summary | ||
Allow unsafe at more positions. | ||
|
||
# Motivation | ||
|
||
When writing unsafe code it's annoying having to write unsafe everywhere. Normally that's a good thing, but sometimes, especially for prototyping, it would sometimes be preferable to be able to declare unsafe for larger blocks. | ||
Maybe it's also helpful for low level code with huge amount of unsafe functions or c interaction. | ||
|
||
# Guide-level explanation | ||
|
||
Unsafe blocks can also be written outside of functions: | ||
``` | ||
unsafe { | ||
fn x() {...} | ||
trait X {...} | ||
... | ||
} | ||
``` | ||
|
||
This will make the elements defined inside the block unsafe. | ||
It will be equivalent to following code: | ||
``` | ||
unsafe fn x() {...} | ||
unsafe trait X {...} | ||
unsafe ... | ||
``` | ||
|
||
Even modules can be declared as unsafe like this: | ||
``` | ||
unsafe mod test { | ||
fn x() {...} | ||
trait X {...} | ||
... | ||
} | ||
``` | ||
|
||
This is almost equivalent to following: | ||
``` | ||
mod test { | ||
unsafe { | ||
fn x() {...} | ||
trait X {...} | ||
... | ||
} | ||
} | ||
``` | ||
But unsafe modules have an additional property. | ||
Using such a module is also unsafe: | ||
``` | ||
unsafe use test; | ||
fn main() { | ||
unsafe { | ||
test::x(); | ||
} | ||
} | ||
``` | ||
|
||
|
||
|
||
# Reference-level explanation | ||
This could just be implemented by some syntactic transformations. | ||
|
||
# Drawbacks | ||
The use of unsafe may be encouraged. | ||
|
||
# Rationale and Alternatives | ||
It may also be possible to add a compiler option to allow unsafe code without declaration. But this option should offer more control about, what is unsafe. | ||
Modules may also declared as unsafe using a feature macro like `#[unsafe]` before the module name or inside the module as `#![unsafe]`. Problem: This is syntactically irregular. Then it would be desirable, that you even declare unsafe functions as following: | ||
``` | ||
#[unsafe] | ||
fn x() {...} | ||
``` | ||
|
||
# Unresolved questions | ||
Should `use` really be `unsafe`? | ||
If it's unsafe to use the module, should calling the functions still be unsafe or will an additional `unsafe` block be needed for calling? | ||
Should whole crates or other things also be able to be declared as unsafe? | ||
How should elements inside the block be handled, if they cannot be declared as unsafe (like variables). | ||
If unsafe fields will be implemented, will it be still required to declare them unsafe explicitely? |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this surprising, because
use
doesn't needunsafe
to import otherunsafe
things:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still perhaps understandable...? With normal modules the entire module isn't necessarily for unsafe stuff. And unsafe use can be good for greppability. Then again, you still have to be in "unsafe mode" to use the functions inside the module, and you can grow for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means that "this could just be implemented by some syntactic transformations" isn't true, though. It's a new concept that
use
rs need to know, but I'm not convinced there's value in it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also wasn't sure if unsafe use is useful. But you don't even need to
use
unsafe functions from safe modules, and just use them at other positions. Maybe just importing things from inside the module as unsafe would make sence? But I think I should removeunsafe
use
from the RFC entirely. What do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say just remove it, especially since it opens a bunch of questions about what paths involving the module would require. For example:
(Thanks to Havvy for inspiration that led to this example.)