LazyLock not working as expected with deref

[Norlock]

I'm not sure if this is a bug inside uuid or LazyLock, but I believe LazyLock should prevent any changes without the lock being acquired.

I tried this code:

<code>
const TA: LazyLock<uuid::Uuid> = LazyLock::new(|| Uuid::new_v4());

pub fn main() {
  info!("{:?} {:?}", *TA, *TA);

}

I expected to see this happen:
Two similar UUID's

Instead, this happened:
[2025-04-26T15:38:56Z INFO splittable_be::templates] 3b9bd2f5-c2e1-433b-962e-1f662acdf5b1 c6258c4c-5bec-4ad5-a5f9-0818ec13537c

Meta

rustc --version --verbose:

rustc 1.86.0 (05f9846f8 2025-03-31)
binary: rustc
commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb
commit-date: 2025-03-31
host: x86_64-unknown-linux-gnu
release: 1.86.0
LLVM version: 19.1.7

[hanna-kruppe]

It’s because TA is a const, not a static. Constants are (conceptually) duplicated into every place where they’re used, which means every execution of *TA creates a new temporary LazyLock independent from the others. Clippy warns about this kind of footgun by default. Arguably rustc should also warn.

[y21]

Arguably rustc should also warn.

#132146 adds this as a lint to rustc as well

[Norlock]

I don't get why doesn't const have a static lifetime? This makes the static more const than const itself?

[theemathas]

A const behaves similarly to if you copy-pasted the code into each point you use the const.

Your code is roughly equivalent to this:

pub fn main() {
  info!("{:?} {:?}", *LazyLock::new(|| Uuid::new_v4()), *LazyLock::new(|| Uuid::new_v4()));
}

[Norlock]

Ok thanks for the explanation, maybe const fields can be better implemented similarly like static to prevent side effects. I guess const also have some benefits over static, shall I close the ticket?

[oli-obk]

jup, I think this is sufficiently tracked by #132146