about summary refs log tree commit diff
path: root/src/libstd/lib.rs
diff options
context:
space:
mode:
authorManish Goregaokar <manishsmail@gmail.com>2020-07-17 18:13:39 -0700
committerGitHub <noreply@github.com>2020-07-17 18:13:39 -0700
commit01418bd1aa71a38567b9fea737d74379133d28c0 (patch)
tree6a20f2af3588da12b1bdb32706866616caf43597 /src/libstd/lib.rs
parentd3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02 (diff)
parentfe639057086fa7bef1e964bf3a211517b04bc328 (diff)
Rollup merge of #72414 - KodrAus:feat/stdlazy, r=Mark-Simulacrum
 Add lazy initialization primitives to std

Follow-up to #68198

Current RFC: https://github.com/rust-lang/rfcs/pull/2788

Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR:

- [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now, but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`.
- [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy`, especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally, if we're adding these types to `std::lazy` instead of `std::sync`, I'd be on-board with not worrying about poisoning in `std::lazy`, and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible, rather than attempting to replicate their behavior. cc @Amanieu @sfackler.
- [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant.

In general, none of these seem to be really blocking an initial unstable merge, so we could possibly kick off a FCP if y'all are happy?

cc @matklad @pitdicker have I missed anything, or were there any other considerations that have come up since we last looked at this?
Diffstat (limited to 'src/libstd/lib.rs')
-rw-r--r--src/libstd/lib.rs5
1 files changed, 5 insertions, 0 deletions
diff --git a/src/libstd/lib.rs b/src/libstd/lib.rs
index 54fc35b20f7..be8d9f7a7c9 100644
--- a/src/libstd/lib.rs
+++ b/src/libstd/lib.rs
@@ -287,6 +287,7 @@
 #![feature(linkage)]
 #![feature(llvm_asm)]
 #![feature(log_syntax)]
+#![feature(maybe_uninit_extra)]
 #![feature(maybe_uninit_ref)]
 #![feature(maybe_uninit_slice)]
 #![feature(min_specialization)]
@@ -294,6 +295,7 @@
 #![feature(negative_impls)]
 #![feature(never_type)]
 #![feature(nll)]
+#![feature(once_cell)]
 #![feature(optin_builtin_traits)]
 #![feature(or_patterns)]
 #![feature(panic_info_message)]
@@ -477,6 +479,9 @@ pub mod process;
 pub mod sync;
 pub mod time;
 
+#[unstable(feature = "once_cell", issue = "74465")]
+pub mod lazy;
+
 #[stable(feature = "futures_api", since = "1.36.0")]
 pub mod task {
     //! Types and Traits for working with asynchronous tasks.