From 3c813bb21257e7bf595fe2cd807b0f1462c675c4 Mon Sep 17 00:00:00 2001 From: Fabio Krapohl Date: Tue, 12 Sep 2017 16:11:16 +0200 Subject: [PATCH 1/2] Create 0000_unsafe_modules.md --- text/0000_unsafe_modules.md | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 text/0000_unsafe_modules.md diff --git a/text/0000_unsafe_modules.md b/text/0000_unsafe_modules.md new file mode 100644 index 00000000000..839750e7020 --- /dev/null +++ b/text/0000_unsafe_modules.md @@ -0,0 +1,79 @@ +- 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. + +# 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? From fb465a355c1e996952e004c37fe45bef5cfb9dd6 Mon Sep 17 00:00:00 2001 From: Fabio Krapohl Date: Sun, 17 Sep 2017 13:46:55 +0200 Subject: [PATCH 2/2] Update 0000_unsafe_modules.md add alternative option `#[unsafe]` --- text/0000_unsafe_modules.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000_unsafe_modules.md b/text/0000_unsafe_modules.md index 839750e7020..d3800117d38 100644 --- a/text/0000_unsafe_modules.md +++ b/text/0000_unsafe_modules.md @@ -70,6 +70,11 @@ 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`?