lazy-static.rs
lazy-static.rs copied to clipboard
Poll: Changing the macro syntax and name
I've been thinking about wether it would make sense to change the macro name and syntax. The main argument here is consistency with std
macros like https://doc.rust-lang.org/std/macro.thread_local.html.
Compare:
thread_local! {
static FOO: u32 = 1;
}
vs
lazy_static! {
static ref FOO: u32 = 1;
}
There are two notable differences:
- The name contains the redundant
_static
. - The
ref
keyword.
The ref
had been chosen to indicate the need for a deref to get to the value, but that's not quite the same as a reference, so thats not really accurate either, and getting rid of it would mean less complexity as you could learn both macros as "normal static syntax inside a special macro invocation".
The lazy_static!
name as opposed to, eg, lazy!
had just been a carry over from before this was even a library, and its main benefit is that with the current macros 1.0, we effectively have a global macro namespace, so a less generic name helps avoiding namespace conflicts.
With macros 2.0 though, a version of this crate would likely offer a proper importable macro, which means you might end up defining lazy statics like this:
extern crate lazy_static;
lazy_static::lazy_static! {
// ...
}
extern crate lazy_static;
use lazy_static::lazy_static; // possible namespace conflict?
lazy_static! {
// ...
}
Both of these make sense to me. I can see myself using lazy_static::lazy!
. I never really care about the ref
, all I did was copy-paste an example and adapt it.
I agree with renaming to lazy!
and getting rid of the ref
.
lazy!
is already used by another crate (https://github.com/reem/rust-lazy). That won't be a problem with macros 2.0 though.
@tmccombs I can't see a use case where you'd want to use both crates at the same time, though. Don't they serve the same purpose?
Don't the serve the same purpose?
Not exactly. lazy_static is used for lazy static variables, whereas lazy is used for arbitrary lazy values. You can use lazy!
to create an array of lazily generated values, you can't do that with lazy_static. On the other hand lazy doesn't have a mechanism to store a lazy value in a static variable.
That said, actual projects that use both are probably pretty rare.
IMO it'd make sense to combine both functions into a single crate. Any reason why they have to be separate?
That makes sense to me.
I agree. Doing so shouldn't be too hard either.
@Kimundi any feelings about this? This is the only significant blocker to 1.0 now afaict.
Alright, with the goal of no longer blocking a 1.0 release, and lacking the time to handle this better, I've decided to postpone this issue for a latter (major) release of the library.
Removing the ref
part of the syntax should be doable in a backwards compatible way anyway, and renaming the macro itself seems to only be feasible once we have stable macros 2.0, and thus can avoid conflicts with other crates.