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

[pitaj]

@rustbot ready

[Amanieu]

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

☔ The latest upstream changes (presumably #125379) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

The purported conflict was from #125310 moving tests/ui/check-static-values-constraints.stderr and #125483 moving compiler/rustc_const_eval/src/transform/check_consts/ops.rs.

There was nothing to resolve; git rebase cleanly handles the changes to moved files.

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit 4913ab8 has been approved by dtolnay

It is now in the queue for this repository.