Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain the difference between Once(Lock|Cell) and Lazy(Lock|Cell) in the docs #124696

Closed
panstromek opened this issue May 4, 2024 · 2 comments · Fixed by #125696
Closed

Explain the difference between Once(Lock|Cell) and Lazy(Lock|Cell) in the docs #124696

panstromek opened this issue May 4, 2024 · 2 comments · Fixed by #125696
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@panstromek
Copy link
Contributor

panstromek commented May 4, 2024

Location

https://doc.rust-lang.org/std/sync/struct.LazyLock.html
https://doc.rust-lang.org/std/sync/struct.OnceLock.html

https://doc.rust-lang.org/std/cell/struct.OnceCell.html
https://doc.rust-lang.org/std/cell/struct.LazyCell.html

Summary

Today I realized these are separate types. I used the experimental LazyLock before without realizing I can actually use stable OnceLock. These types are so similar that I never realized there are two of them.

Still, I don't think I quite understand the difference and the tradeoff (e.g. is some of them faster or not?). It would be useful if the docs pages linked to each other and explained the difference.

@panstromek panstromek added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label May 4, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 4, 2024
@workingjubilee
Copy link
Member

LazyLock is an API you can build on top of OnceLock, and is the "obvious one" to use in many cases. OnceLock permits more potential use-cases, being the more basic form, but also often is additional complication if you wanted LazyLock.

@workingjubilee workingjubilee added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label May 4, 2024
@workingjubilee
Copy link
Member

...so it should probably say something like that, yes.

@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 4, 2024
@bors bors closed this as completed in ee04e0f Jun 4, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jun 4, 2024
Rollup merge of rust-lang#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 rust-lang#124696
Fixes rust-lang#125615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants