Officially deprecate lazy_static

[KodrAus]

lazy_static has served the community well over the better part of a decade. Over that time, the Rust language has evolved, and better alternatives built on that evolution have emerged. That functionality has now made its way into the standard library, with aspects of it stabilizing from 1.70.0.

This library hasn't seen steady maintainership in some time. To support migration off lazy_static and towards once_cell or the standard library's types I propose we formally deprecate this library.

cc @rust-lang-nursery/libs-contributors

[Fishrock123]

I think this library is still worth having, but with it's implementation switched to once_cell.

The interface of lazy_static is often much better for use cases where there isn't much worry of fallibility or misordering.

E.g. static regexes from string literals.

[frewsxcv]

I opened a PR for documenting in the README that one can now utilize the stable std::sync::OnceLock: #216

[lordofpipes]

I think this library is still worth having, but with it's implementation switched to once_cell.

The interface of lazy_static is often much better for use cases where there isn't much worry of fallibility or misordering.

E.g. static regexes from string literals.

Are there currently any alternatives that provide a macro on top of std::cell::OnceCell and std::sync::OnceLock? It seems like LazyCell standardization is still being debated because of its usage of an extra function pointer to a closure at runtime.

[frewsxcv]

OnceLock is simple enough in my opinion. A macro would only save you a few characters, if any.

use std::collections::HashMap;
use std::sync::OnceLock;

fn hashmap() -> &'static HashMap<u32, &'static str> {
    static HASHMAP: OnceLock<HashMap<u32, &str>> = OnceLock::new();
    HASHMAP.get_or_init(|| {
        let mut m = HashMap::new();
        m.insert(0, "foo");
        m.insert(1, "bar");
        m.insert(2, "baz");
        m
    })
}

fn main() {
    // First access to `HASHMAP` initializes it
    println!("The entry for `0` is \"{}\".", hashmap().get(&0).unwrap());

    // Any further access to `HASHMAP` just returns the computed value
    println!("The entry for `1` is \"{}\".", hashmap().get(&1).unwrap());
}

[CountingBeeps]

While a bit niche, this crate is commonly used in #![no_std] projects. If this is deprecated an alternative will be needed.

This usecase makes swapping to a oncelock wrapper potentially problematic.

Edit: Looking at OnceCell, it might be a suitable alternative.

[KodrAus]

@Kimundi Sorry, it looks like I managed to miss this until the invite expired 🙃 Is there any chance of resending it? I can see us going around in circles a bit here though so if I ping a random member of the nursery team with permissions to push............ @cuviper could I trouble you to cargo publish the master branch here? It's all ready to go 🙏

[cuviper]

Published!

[KodrAus]

Thanks @cuviper!

[tgross35]

While a bit niche, this crate is commonly used in #![no_std] projects. If this is deprecated an alternative will be needed.

This usecase makes swapping to a oncelock wrapper potentially problematic.

Edit: Looking at OnceCell, it might be a suitable alternative.

OnceCell or LazyCell (in core::cell) are usable with no_std if they don't need to be statics. For cases where you do want a global static, spin::Lazy is now available as a no_std version of std::sync::LazyLock.

---

Two cents: I don't think this repo should be deprecated until OnceLock and LazyLock have been around long enough to make it into Debian / RHEL stable. It doesn't seem like a good idea to give everyone an unmaintained advisory for lazy-static and force changing to once_cell if they can't directly jump to LazyLock for MSRV reasons.

[cuviper]

RHEL 9.4 and 8.10 both have Rust 1.75, so they have OnceCell and OnceLock now. Rust 1.80 will be a while yet for RHEL to get LazyCell and LazyLock, but I think once_cell is still worthwhile in the meantime.

The "unmaintained" status here is true whether we issue an advisory or not.

[rimutaka]

What are the alternatives for async?
This works:

// Cannot use std::cell::OnceCell because it does not support async initialization
lazy_static! {
    pub(crate) static ref CONFIG: AsyncOnce<Config> = AsyncOnce::new(async { Config::from_env().await });
}

[SimonSapin]

tokio::sync::OnceCell supports async initialization. (The "sync" in tokio::sync refers to thread-safe synchronization like std::sync, it does not mean not-async.)

[kennytm]

The example in #214 (comment) is more like a LazyCell though.

The problems reducing usability of LazyCell-style initialization are

1. You need #![feature(const_async_blocks)]¹. (This use-side feature can be avoided if the cell is initialized with AsyncFnOnce() -> T rather than Future<Output=T>, in exchange for the definition-side #![feature(async_closure)])

2. Unlike LazyCell which you can default the initializer to fn() -> T, there is no static type for the async block, so you need to separately define a TAIT², making the code pretty messy like:

   #![feature(const_async_blocks, type_alias_impl_trait)]
   type ConfigFuture = impl Future<Output = Config>;
   static CONFIG: AsyncLazyCell<ConfigFuture> = AsyncLazyCell::new(async { 
       Config::from_env().await 
   });

   sample (slow) implementation of AsyncLazyCell

   use std::future::Future;
   use std::sync::Mutex;
   use tokio::sync::OnceCell;
   
   struct AsyncLazyCell<F: Future> {
       cell: OnceCell<F::Output>,
       initializer: Mutex<Option<F>>,
   }
   
   impl<F: Future> AsyncLazyCell<F> {
       pub const fn new(f: F) -> Self {
           Self {
               cell: OnceCell::const_new(),
               initializer: Mutex::new(Some(f)),
           }
       }
       
       pub async fn get(&self) -> &F::Output {
           self.cell.get_or_init(|| {
               let mut guard = self.initializer.lock().unwrap();
               let future = guard.take();
               drop(guard);
               future.expect("poisoned or something")
           }).await
       }
   }

   async_once³ works-around this by storing the future as dynamic Box<dyn Future<Output = T>>, but outside of lazy_static! I think you can only ask the user call Box::pin themselves in the static declaration, not hidden away in the const fn new().

Footnotes

1. Tracking Issue for async {} blocks in const expressions rust-lang/rust#85368 ↩

2. thus requiring #![feature(type_alias_impl_trait)], Tracking issue for RFC 2515, "Permit impl Trait in type aliases" rust-lang/rust#63063 ↩

3. https://docs.rs/async_once ↩