-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Officially deprecate lazy_static #214
Comments
To align more with the upcoming standardizations within the Rust ecosystem which started with the release of `1.70.0` and the inevitable deprecation of `lazy_static`: rust-lang-nursery/lazy-static.rs#214
To align more with the upcoming standardizations within the Rust ecosystem which started with the release of `1.70.0` and the inevitable deprecation of `lazy_static`: rust-lang-nursery/lazy-static.rs#214
To align more with the upcoming standardizations within the Rust ecosystem which started with the release of `1.70.0` and the inevitable deprecation of `lazy_static`: rust-lang-nursery/lazy-static.rs#214
I think this library is still worth having, but with it's implementation switched to The interface of E.g. static regexes from string literals. |
I opened a PR for documenting in the README that one can now utilize the stable |
Are there currently any alternatives that provide a macro on top of |
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());
} |
I would agree that macro_rules! lazy_static {
($name: ident: $ty: ty = $expr: expr) => {
::paste::paste! {
struct [<__ $name:camel>];
#[allow(unused)]
static [<$name:upper>]: [<__ $name:camel>] = [<__ $name:camel>];
impl ::std::ops::Deref for [<__ $name:camel>] {
type Target = $ty;
fn deref(&self) -> &Self::Target {
static S: ::std::sync::OnceLock<$ty> = ::std::sync::OnceLock::new();
S.get_or_init(|| $expr)
}
}
}
};
{$(static ref $name: ident: $ty: ty = $expr: expr;)+} => {
$(lazy_static!($name: $ty = $expr);)+
};
} Use it just like normal: lazy_static! {
static ref CARGO_MANIFEST_DIR: PathBuf = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
static ref OUT_DIR: PathBuf = PathBuf::from(var("OUT_DIR").unwrap());
}
...
let my_path = OUT_DIR.join("my-file.txt"); * This is poorly tested and likely rife with design issues, but it does work |
For what its worth, I'dd support both deprecating the library, or turning it into a thin wrapper around the std types that make it obsolete. |
@KodrAus Is this still a "proposal," or is If the latter:
|
Even if |
Sure. But notice that the version in this repo is 1.5.0, but the version published to crates.io is 1.4.0. According to #201 (comment), @KodrAus does not have permissions to publish So even if someone rewrote this package as a wrapper around The only other alternative I can think of is if someone wanted to maintain a fork. |
I was not aware that there is a permission problem here (which is unsurprising, seeing how the reason I originally shared ownership with the libs team was that I was unable to pay attention to my libraries consistently over time....) @KodrAus - what do you need? Just the crates.io co-ownership? |
@smoelius I think it's still a proposal, but it is effectively unmaintained in practice. @Kimundi I think co-ownership would let me push the current changeset up to @SimonSapin what do you see as the value of this macro over a library like |
Like @attackgoat mentioned, it's still nice to be able to shorten it. The shortest equivalent still requires repeating the type definition twice. It's a macro I would have written anyways regardless of how it works under the hood, so if it were available as a 2.0 of this crate it might be nice. If not I'm not complaining either, keeping the current implementation and deprecating the crate is a more safe option anyways. |
@KodrAus Sorry, another month went by too fast 😅 I just sent you the crates.io ownership invite. |
While a bit niche, this crate is commonly used in This usecase makes swapping to a oncelock wrapper potentially problematic. Edit: Looking at OnceCell, it might be a suitable alternative. |
@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 |
Published! |
Thanks @cuviper! |
Two cents: I don't think this repo should be deprecated until |
RHEL 9.4 and 8.10 both have Rust 1.75, so they have The "unmaintained" status here is true whether we issue an advisory or not. |
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 from1.70.0
.This library hasn't seen steady maintainership in some time. To support migration off
lazy_static
and towardsonce_cell
or the standard library's types I propose we formally deprecate this library.cc @rust-lang-nursery/libs-contributors
The text was updated successfully, but these errors were encountered: