From 1e5c6030cf48a3021b59dc898c7d0c8f7ec12bcf Mon Sep 17 00:00:00 2001 From: Carl Lerche Date: Wed, 25 Feb 2015 09:40:45 -0800 Subject: [PATCH 1/2] Move `std::thread_local::*` into `std::thread` --- text/0000-move-thread-local-to-std-thread.md | 49 ++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 text/0000-move-thread-local-to-std-thread.md diff --git a/text/0000-move-thread-local-to-std-thread.md b/text/0000-move-thread-local-to-std-thread.md new file mode 100644 index 00000000000..eb059b92871 --- /dev/null +++ b/text/0000-move-thread-local-to-std-thread.md @@ -0,0 +1,49 @@ +- Feature Name: N/A +- Start Date: 2015-02-25 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary + +Move the contents of `std::thread_local` into `std::thread`. Fully +remove `std::thread_local` from the standard library. + +# Motivation + +Thread locals are directly related to threading. Combining the modules +would reduce the number of top level modules, making browsing the docs +easier as well as reduce the number of `use` statements. + +# Detailed design + +The goal is to move the contents of `std::thread_local` into +`std::thread`. There are a few possible strategies that could be used to +achieve this. + +One option would be to move the contents as is into `std::thread`. This +would leave `Key` and `State` as is. There would be no naming conflict, +but the names would be less ideal since the containing module is not +directly related to thread locals anymore. This could be handled by +renaming the types to something like `LocalKey` and `LocalState`. + +Another option would be to move the contents into a dedicated sub module +such as `std::thread::local`. This would mean some code would still have +an extra `use` statement for pulling in thread local related types, but +it would also enable doing: + +`use std::thread::{local, Thread};` + +# Drawbacks + +It's pretty late in the 1.0 release cycle. This is a mostly bike +shedding level of a change. It may not be worth changing it at this +point and staying with two top level modules in `std`. Also, some users +may prefer to have more top level modules. + +# Alternatives + +Leaving `std::thread_local` in its own module. + +# Unresolved questions + +The exact strategy for moving the contents into `std::thread` From 50ff468f9b1d7bafb912374e7df2c51329112d6e Mon Sep 17 00:00:00 2001 From: Carl Lerche Date: Thu, 26 Feb 2015 21:29:21 -0800 Subject: [PATCH 2/2] Focus on a single `std::thread_local` renaming strategy --- text/0000-move-thread-local-to-std-thread.md | 32 +++++++++----------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/text/0000-move-thread-local-to-std-thread.md b/text/0000-move-thread-local-to-std-thread.md index eb059b92871..cde24abdd5b 100644 --- a/text/0000-move-thread-local-to-std-thread.md +++ b/text/0000-move-thread-local-to-std-thread.md @@ -11,27 +11,21 @@ remove `std::thread_local` from the standard library. # Motivation Thread locals are directly related to threading. Combining the modules -would reduce the number of top level modules, making browsing the docs -easier as well as reduce the number of `use` statements. +would reduce the number of top level modules, combine related concepts, +and make browsing the docs easier. It also would have the potential to +slightly reduce the number of `use` statementsl # Detailed design -The goal is to move the contents of `std::thread_local` into -`std::thread`. There are a few possible strategies that could be used to -achieve this. +The `std::thread_local` module would be renamed to `std::thread::local`. +All contents of the module would remain the same. This way, all thread +related code is combined in one module. -One option would be to move the contents as is into `std::thread`. This -would leave `Key` and `State` as is. There would be no naming conflict, -but the names would be less ideal since the containing module is not -directly related to thread locals anymore. This could be handled by -renaming the types to something like `LocalKey` and `LocalState`. +It would also allow using it as such: -Another option would be to move the contents into a dedicated sub module -such as `std::thread::local`. This would mean some code would still have -an extra `use` statement for pulling in thread local related types, but -it would also enable doing: - -`use std::thread::{local, Thread};` +```rust +use std::thread::{local, Thread}; +``` # Drawbacks @@ -42,7 +36,11 @@ may prefer to have more top level modules. # Alternatives -Leaving `std::thread_local` in its own module. +Another strategy for moving `std::thread_local` would be to move it +directly into `std::thread` without scoping it in a dedicated module. +There are no naming conflicts, but the names would not be ideal anymore. +One way to mitigate would be to rename the types to something like +`LocalKey` and `LocalState`. # Unresolved questions