Stabilize LazyCell and LazyLock

[pitaj]

Closes #109736

This stabilizes the LazyLock and LazyCell types:

static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
    println!("initializing");
    let mut m = HashMap::new();
    m.insert(13, "Spica".to_string());
    m.insert(74, "Hoyten".to_string());
    m
});

let lazy: LazyCell<i32> = LazyCell::new(|| {
    println!("initializing");
    92
});

r? libs-api

[m-ou-se]

sidestepping the unresolved questions

It is not fully clear to me which issues this sidesteps. Can you add some clarifications of what is and isn't allowed after this PR, and what a possible upgrade path looks like to a future where LazyCell/LazyLock don't unnecessarily store a function pointer in memory?

[pitaj]

@m-ou-se

Unresolved Questions

1. Default F = fn() -> T in type signature (See comment)

Summary: LazyLock<T, F = fn() -> T> is a hack to make static FOO: Lazy<T> work. (It's also not ideal to store a function pointer in memory unnecessarily). Any alternatives would require new language features.

With the unstable default type parameter, specifying the second type parameter is an error. The only way to get a LazyLock<Thing, {closure}> is via type inference on local variables:

// LazyLock<String, {closure}>
let foo = LazyLock::new(|| "foo".to_string());

// LazyLock<String, fn() -> String>
let bar: LazyLock<String> = LazyLock::new(|| "bar".to_string());

// LazyLock<String, fn() -> String>
static STAT: LazyLock<String> = LazyLock::new(|| "stat".to_string());

Some future possibilities that would allow avoiding the function pointer:

// Just "opaque type inference in statics"
pub static LazyLock<T, F = fn() -> T> { ... }
// lint the missing type parameter
static FOO: LazyLock<String> = ...;
// recommend setting it to infer the closure type
static FOO: LazyLock<String, _> = ...;

// "Opaque type inference in statics" and "type parameter default infer"
pub struct LazyLock<T, F = _> { ... }
static FOO: LazyLock<String> = ...;

// "`impl Trait` in statics" and "type parameter default `impl Trait`"
pub struct LazyLock<T, F = impl FnOnce() -> T> { ... }
static FOO: LazyLock<String> = ...;

2. Is variance of Lazy correct? (See
   Feature request: Make Lazy<T, F> covariant in F matklad/once_cell#167)

Summary: LazyLock<T, F> is currently invariant in F. Using a type including a lifetime for F can cause "insurmountable" lifetime issues. @matklad agrees that covariance would be better, but it would complicate the implementation (or may be impossible). Nobody has implemented F-covariance for once_cell::*::Lazy yet.

Because the unstable type parameter can't be specified explicitly, it's impossible to set it to a type which can cause those variance issues. The only remotely possible way would be type inference in a local variable, but I can't think of a way that could cause issues, if it's possible at all.

There are only two possible futures here:

• Lazy* are modified to be covariant in F and the parameter is later stabilized
• The parameter is stabilized as-is, invariant in F

@rustbot ready

[tgross35]

cc @danielhenrymantilla who did a lot of the variance work for once_cell

[tgross35]

@m-ou-se is the response in #121377 (comment) sufficient to get this nominated again?

[Amanieu]

We discussed this in a libs-api meeting and decided for a full stabilization of these types as they are right now, including stabilizing the F generic argument.

The reason for also stabilizing F is that even if in the future we get some form of type inference for static, we could just use a lint to suggest using _ to infer F. We expect that if we do get type inference in the future then it is likely that people will end up omitting the type entirely in favor of inference anyways.

Regarding the variance of F, it's not a breaking change to make it co-variant later.

[pitaj]

Great news! I will soon modify this PR to fully stabilize, rather than leaving F unstable.

[rustbot]

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

[RalfJung]

@danielhenrymantilla yeah that's what I would think, similar to how Mutex<()> is sometimes used as a lock where the guarded data (unsafely) lives "outside" the lock.

[RalfJung]

I filed an issue for that: #125615

[slanterns]

Actually people have already discussed replacing Once by OnceLock<()> before, but whether it worth the breakage or not remains a question.

[DoubleHyphen]

I tried this code:

use std::sync::LazyLock;
use std::collections::HashMap;

static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
    println!("initializing");
    let mut m = HashMap::new();
    m.insert(13, "Spica".to_string());
    m.insert(74, "Hoyten".to_string());
    m
});

fn main() {
    println!("{:?}", &HASHMAP);
    HASHMAP.get(&74);
    println!("{:?}", &HASHMAP);
}

And got this output:

LazyLock(<uninit>)
initializing
LazyLock({74: "Hoyten", 13: "Spica"})

Is this the expected behaviour? Is it illegal to attempt to print a static LazyLock before doing anything else with it?

[pitaj]

@DoubleHyphen these Lazy types have explicit Debug impls that will tell you if the object is not initialized. That's what you're seeing with the LazyLock(<uninit>) output. It's expected behavior.

[RalfJung]

@DoubleHyphen what makes you think that anything illegal happened?

[DoubleHyphen]

@DoubleHyphen what makes you think that anything illegal happened?

Terse version: I was expecting printing the LazyLock to constitute using it; thus, I expected it to be printed initialised.

---

Verbose version:

As I saw this thread, I was immediately reminded of Graydon Hoare's famous article, things rust shipped without. One of those things was

variables with runtime "before main" static initialization

which at first glance seemed at odds with this here feature.

But then I thought “Wait. The clue is in the name. Those variables ought to be initialised before their first use, not before main.“ So I whipped up an example in order to experiment and see when they would be initialised.

Now when it comes to lazy iterators, their uninitialised state is not observable; as soon as one tries to do anything with them, they are immediately initialised. I had expected the same to be true of LazyLocks; thus, I expected printing it to initialise it. It was therefore a bit astonishing to me to realise that this was not the case.

Maybe clear documentation will fix this issue, or at least assuage it. But for now, in its absence, there is no clear way to use a LazyLock to, for instance, get the user's name from the terminal and then print it. How do you persuade the compiler to consider a static LazyLock<String> used, if not by printing it?

I'm not convinced that force is the correct API design choice, but I'll defer to the more experienced folks.

[RalfJung]

How do you persuade the compiler to consider a static LazyLock used, if not by printing it?

I am confused by the question, since your example already does that: you just deref it. Your own code does that when calling get. HASHMAP.get ensures it has been initialized. If you want to debug-print the contents of the LazyCell (rather than debug-printing the LazyCell itself), use println!("{:?}", *HASHMAP);, the * makes the deref explicit that is added implicitly when calling get.

I don't quite understand the problem here. Anyway a merged PR is a bad place for discussion, please open an issue describing the expected and actual behavior, or otherwise clarifying what you are missing in the current API surface.

[elichai]

It's too bad we have to go through a function pointer and not directly through the ZST, is there no way to somehow make inference or <T = impl FnOnce()> (does it even make sense?) something that will allow us to cover us a generic, maybe with TAIT somehow?

EDIT: This was already discussed above

[pitaj]

@elichai I don't think TAIT can help us, since every closure has a unique type. A few possibilities are discussed here, IMO the best option is "type inference in statics". Then the following would just work:

static LAZY_FOO = LazyLock::new(|| "foo".to_uppercase());