Skip to content

Replace OnceLock with LazyLock #256

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

Merged
merged 2 commits into from
Apr 23, 2025
Merged

Replace OnceLock with LazyLock #256

merged 2 commits into from
Apr 23, 2025

Conversation

russellbanks
Copy link
Contributor

LazyLock is simpler than OnceLock and the docs suggest its use over OnceLock in simple cases where different initializers based on the caller are not required:

In many simple cases, you can use LazyLock<T, F> instead to get the benefits of this type with less effort: LazyLock<T, F> “looks like” &T because it initializes with F on deref! Where OnceLock shines is when LazyLock is too simple to support a given case, as LazyLock doesn’t allow additional inputs to its function after you call LazyLock::new(|| ...).

OnceCell was used in #160 (and therefore #179) as it became stable in v1.70 whilst LazyLock became stable in v1.80. With the MSRV bump of keyring v4 to v1.85, this is no longer a consideration.

Copy link
Collaborator

@brotskydotcom brotskydotcom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks a lot!

@brotskydotcom brotskydotcom merged commit 54a423f into open-source-cooperative:master Apr 23, 2025
11 checks passed
@russellbanks russellbanks deleted the lazylock branch April 23, 2025 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants