diff options
| author | Manish Goregaokar <manishsmail@gmail.com> | 2020-07-17 18:13:39 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-07-17 18:13:39 -0700 |
| commit | 01418bd1aa71a38567b9fea737d74379133d28c0 (patch) | |
| tree | 6a20f2af3588da12b1bdb32706866616caf43597 /src/libstd/lib.rs | |
| parent | d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02 (diff) | |
| parent | fe639057086fa7bef1e964bf3a211517b04bc328 (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.rs | 5 |
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. |
