lazy-static.rs icon indicating copy to clipboard operation
lazy-static.rs copied to clipboard

Poll: Changing the macro syntax and name

Open Kimundi opened this issue 7 years ago • 10 comments

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! {
    // ...
}

Kimundi avatar Apr 12 '17 09:04 Kimundi

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.

Apanatshka avatar Apr 14 '17 13:04 Apanatshka

I agree with renaming to lazy! and getting rid of the ref.

clarfonthey avatar Apr 14 '17 17:04 clarfonthey

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 avatar May 12 '17 05:05 tmccombs

@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?

clarfonthey avatar May 12 '17 22:05 clarfonthey

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.

tmccombs avatar May 13 '17 04:05 tmccombs

IMO it'd make sense to combine both functions into a single crate. Any reason why they have to be separate?

clarfonthey avatar May 24 '17 21:05 clarfonthey

That makes sense to me.

tmccombs avatar May 24 '17 22:05 tmccombs

I agree. Doing so shouldn't be too hard either.

Ericson2314 avatar May 29 '17 15:05 Ericson2314

@Kimundi any feelings about this? This is the only significant blocker to 1.0 now afaict.

brson avatar Jul 06 '17 01:07 brson

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.

Kimundi avatar Nov 08 '17 11:11 Kimundi