diff options
| author | Guillaume Gomez <guillaume1.gomez@gmail.com> | 2024-06-04 21:41:34 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-06-04 21:41:34 +0200 |
| commit | ee04e0f35ed516e4f1cc6a12c28838eaf98a16d1 (patch) | |
| tree | 85e30780823cb13f3645fbed0db1a6c7ad05632b /compiler/rustc_interface/src | |
| parent | fa96e2cb4f1b0b1c4de128005658826631ed1d10 (diff) | |
| parent | 9ed7cfc952b06fb4e552fb02bbd65070e56cfdc0 (diff) | |
| download | rust-ee04e0f35ed516e4f1cc6a12c28838eaf98a16d1.tar.gz rust-ee04e0f35ed516e4f1cc6a12c28838eaf98a16d1.zip | |
Rollup merge of #125696 - workingjubilee:please-dont-say-you-are-lazy, r=Nilstrieb
Explain differences between `{Once,Lazy}{Cell,Lock}` types
The question of "which once-ish cell-ish type should I use?" has been raised multiple times, and is especially important now that we have stabilized the `LazyCell` and `LazyLock` types. The answer for the `Lazy*` types is that you would be better off using them if you want to use what is by far the most common pattern: initialize it with a single nullary function that you would call at every `get_or_init` site. For everything else there's the `Once*` types.
"For everything else" is a somewhat weak motivation, as it only describes by negation. While contrasting them is inevitable, I feel positive motivations are more understandable. For this, I now offer a distinct example that helps explain why `OnceLock` can be useful, despite `LazyLock` existing: you can do some cool stuff with it that `LazyLock` simply can't support due to its mere definition.
The pair of `std::sync::*Lock`s are usable inside a `static`, and can serve roles in async or multithreaded (or asynchronously multithreaded) programs that `*Cell`s cannot. Because of this, they received most of my attention.
Fixes #124696
Fixes #125615
Diffstat (limited to 'compiler/rustc_interface/src')
0 files changed, 0 insertions, 0 deletions
