Tracking Issue for `lazy_cell` #109736

tgross35 · 2023-03-29T19:50:23Z

Note: lazy_cell_consume is now tracked at #125623

This supercedes #74465 after a portion of once_cell was stabilized with #105587

Feature gate: #![feature(lazy_cell)]

This is a tracking issue for the LazyCell and LazyLock types, which are designed to support convenient one-time initialization. One of the main goals is to be able to replace the lazy_static crate, as well as once_cell::{sync, unsync}::Lazy.

Public API

// core::cell (in core/src/cell/lazy.rs)

pub struct LazyCell<T, F = fn() -> T> { /* ... */ }

impl<T, F: FnOnce() -> T> LazyCell<T, F> {
    pub const fn new(init: F) -> LazyCell<T, F>;
    pub fn force(this: &LazyCell<T, F>) -> &T;
}

impl<T, F: FnOnce() -> T> Deref for LazyCell<T, F> {
    type Target = T;
}

impl<T: Default> Default for LazyCell<T>;
impl<T: fmt::Debug, F> fmt::Debug for LazyCell<T, F>;

// std::sync (in std/sync/lazy_lock.rs)

pub struct LazyLock<T, F = fn() -> T> { /* ... */ }

impl<T, F: FnOnce() -> T> LazyLock<T, F> {
    pub const fn new(f: F) -> LazyLock<T, F>;
    pub fn force(this: &LazyLock<T, F>) -> &T;
}

impl<T, F> Drop for LazyLock<T, F>;
impl<T, F: FnOnce() -> T> Deref for LazyLock<T, F> {
    type Target = T;
}
impl<T: Default> Default for LazyLock<T>;
impl<T: fmt::Debug, F> fmt::Debug for LazyLock<T, F>;

// We never create a `&F` from a `&LazyLock<T, F>` so it is fine
// to not impl `Sync` for `F`
unsafe impl<T: Sync + Send, F: Send> Sync for LazyLock<T, F>;
// auto-derived `Send` impl is OK.
impl<T: RefUnwindSafe + UnwindSafe, F: UnwindSafe> RefUnwindSafe for LazyLock<T, F>;
impl<T: UnwindSafe, F: UnwindSafe> UnwindSafe for LazyLock<T, F>;

Steps / History

Implementation: Add lazy initialization primitives to std #72414
Final comment period (FCP)¹
Stabilization PR - Stabilize LazyCell and LazyLock #121377

Unresolved Questions

Is variance of Lazy correct? (See Feature request: Make Lazy<T, F> covariant in F matklad/once_cell#167)
Default F = fn() -> T in type signature (See Tracking Issue for lazy_cell #109736 (comment))

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

The text was updated successfully, but these errors were encountered:

tgross35 · 2023-03-29T21:49:22Z

cc original authors @matklad and @KodrAus, just for reference

matklad · 2023-03-29T22:29:57Z

The biggest design question here is the default parameter: F = fn() -> T

It is a hack to make static MY_DATA: Lazy<MyType> = ... syntax work.
One can imagine static MY_DATA: Lazy<MyType, _> working one day, but at this point it seems more likely than not that we won't ever implement this kind of inference, and, even if we end up implementing something like that, it would be years in the future.
The hack works out nicely in 99% of the cases, but it can create confusion when using Lazy for a local variable:

let env = "hello".to_string();

let ok1 = Lazy::new(|| env);
let ok2: Lazy<String, _> = Lazy::new(|| env);

let err: Lazy<String> = Lazy::new(|| env);
// ^ The confusing case. The problem here is that type of `F` isn't inferred, 
/// but is taken from the default

tgross35 · 2023-03-29T23:24:31Z

It is kind of weird to have the F be a part of the type definition at all. It makes sense of course as far as needing to store the function type in the struct, but it's a bit clunky for type signatures.

Is there a workaround using with raw function pointers maybe? Since the signature is always known, but I'm not sure how things like closure coercions & lifetimes would work here.

Or maybe dynamics could work. I haven't thought it totally through (and there might be lifetime trickiness) but at least the std LazyLock could store a Box<dyn FnOnce() -> T>

Sp00ph · 2023-03-30T01:06:06Z

Boxing the contents would make it unusable for static values which would render it useless for most use cases.

tgross35 · 2023-03-30T01:21:25Z

Yeah, that is a good point. And &dyn isn't very elegant.

Just spitballing here... taking a fn() -> T would eliminate the second parameter. This would unfortunately mean that it can't take environment-capturing closures, blocking the examples matklad pointed out. At least for LazyLock though, I can't really envision any use cases where this would be desired anyway. And it would allow for a nonbreaking upgrade to FnOnce in the future, if there is ever a better way.

pub struct TestLazyLock<T> {
    cell: OnceLock<T>,
    init: Cell<Option<fn() -> T>>,
}

impl<T> TestLazyLock<T> {
    const fn new(init: fn() -> T) -> Self {
        Self { cell: OnceLock::new(), init: Cell::new(Some(init)) }
    }
}

playground

Sp00ph · 2023-03-30T01:29:22Z

I don't see how that would be preferable over just having the second type parameter with the fn() -> T default. Granted, the case mentioned by @matklad currently doesn't provide a very good diagnostic, but if the compiler just suggested to add the _ as the second type parameter then that point of confusion would probably also largely disappear.

SUPERCILEX · 2023-03-30T02:55:53Z

Regarding #106152, does anyone know if the initialization state was explicitly excluded from the API? That was @Amanieu's concern.

tgross35 · 2023-03-30T03:02:15Z

Yeah, it's not preferable. Just trying to see if there's any way where we could either

not have that generic parameter, or
make it so users can never write LazyCell<T, _> or LazyCell<T, fn() -> T> - so we could eventually drop the second parameter in a background-compatible way. I don't think this is possible via sealing or anything, but maybe there's a tricky way.

To quote @m-ou-se in #74465 (comment)

It's a bit of a shame that Lazy uses a fn() -> T by default. With that type, it needlessly stores a function pointer even if it is constant. Would it require big language changes to make it work without storing a function pointer (so, a closure as ZST), while still being as easy to use? Maybe if captureless closures would implement some kind of const Default? And some way to not have to name the full type in statics. That's probably not going to happen very soon, but it'd be a shame if this becomes possible and we can't improve Lazy because the fn() -> T version was already stabilized. Is there another way to do this?

I think that the form I suggested above with TestLazyLock<T> would be forward-compatible with either something like what Mara is suggesting, or with the current form (could use a sanity check here). It's not as useful as the current full featured version, but it does directly replace the purpose of lazy_static, which is kind of the biggest target of this feature. So in theory, that could be stabilized while a more full featured version is being contemplated.

tgross35 · 2023-03-30T03:34:07Z

Regarding #106152, does anyone know if the initialization state was explicitly excluded from the API? That was @Amanieu's concern.

I am not super in the know for this, but I don't think there's any particular reason the state couldn't be exposed somehow. The state is known by the OnceCell, and would have to be tracked somehow even with a different underlying implementation.

bstrie · 2023-03-30T20:54:48Z

make it so users can never write LazyCell<T, _> or LazyCell<T, fn() -> T> - so we could eventually drop the second parameter in a background-compatible way

I somewhat doubt it would ever be necessary to make such a change (the only edge case is rather contrived), but even then the way to drop the second parameter in a backward-compatible way would be to introduce a new API, deprecate this one, and upgrade everyone with cargo fix. I wouldn't stress about the existence of this parameter.

NobodyXu · 2023-03-31T00:39:40Z

If "impl trait" is allowed in let/static/const #63065 then the additional parameter is not an issue anymore.

If the Lazy is initialized with a closure, then using "impl trait" in static would actually reduce size of the global variable by one function pointer.

tgross35 · 2023-03-31T01:15:47Z

@NobodyXu I'm not too familar with that feature... would it also allow these impl definitions in structs? Or what would this look like? I'm imagining something like this, which would be quite cool

type LazyInitFn<T> =  impl FnOnce() -> T + Send + ?Sized;

pub struct LazyLock<T> {
    cell: OnceLock<T>,
    init: Cell<Option<LazyInitFn<T>>>,
}

impl<T> LazyLock<T> {
    const fn new(init: LazyInitFn<T>) -> Self { /* ... */ }
}

But I haven't seen any examples in the RFC that do this

NobodyXu · 2023-03-31T01:29:06Z

@NobodyXu I'm not too familar with that feature... would it also allow these impl definitions in structs? Or what would this look like? I'm imagining something like this, which would be quite cool

Oh you are right, I missed that.

According to my understanding, it enables something like this:

static F: impl FnOnce() -> u32 = || 1;

I was thinking about:

static F: Lazy<impl FnOnce() -> u32> = Lazy::new(|| 1);

Which might not be covered by the tracking issue I linked.

matklad · 2023-04-02T16:40:30Z

Added matklad/once_cell#167 as an unresolved quesrion

tgross35 · 2023-04-03T06:28:10Z

Is there a reason force is an associated function rather than taking &self? No specific comment, just curious.

bjorn3 · 2023-04-03T07:11:45Z

I presume to avoid shadowing a .force() method on the inner value.

tgross35 · 2023-04-03T07:23:08Z

Makes sense. It does sort of remind me of the discussion on Mutex::unlock, but I do think it makes more sense here.

slanterns · 2023-04-03T07:29:48Z

Unlike Mutex, LazyCell is newly added to std. Why will it still suffer from the possible shadowing?

tgross35 · 2023-04-03T08:03:22Z

Bjorn meant that if whatever the LazyCell derefs to (T) has a .force method, then that would overlap with the LazyCells's own .force.

I just linked Mutex::unlock because it was recently decided against for just being a synonym for drop, and it has a similar signature to LazyCell::force - which is a synonym for deref. Just something to consider whether any arguments against unlock might apply here: I don't think they do, since force isn't trying to encourage a way around any usage patterns (unlock was sort of an escape hatch for RAII).

nbdd0121 · 2023-04-06T09:07:33Z

This works on nightly, if TAIT is enabled:

type F = impl FnOnce() -> ();
static L: LazyLock<(), F> = LazyLock::new(|| ());

once_cell supersets lazy_static features and its API is better and "soon" to be stabilized in the standard library: rust-lang/rust#109736

rust-lang/rust#109736

SUPERCILEX · 2023-04-24T00:18:40Z

The lazy_cell_consume feature was added as part of this tracking issue: #106152. It is part of the Lazy* API, but does not have to be stabilized with the base feature set.

joboet · 2024-05-04T17:47:09Z

Shouldn't LazyCell/LazyLock be also covariant over T? From a type system perspective, &LazyCell<T, F> is basically just a &(T, F) which dynamically chooses between calling F or returning a reference to T. This would e.g. allow using a &LazyCell<&'static i32, fn() -> &'static i32> where a &LazyCell<&'a i32, fn() -> &'a i32> was expected.

This might be very difficult to achieve, but if the tree borrows model for interior mutability ends up being used, I can see a way (by adding a Cell<()> field, we can remove the UnsafeCell around the state and still legally mutate it).

Plecra · 2024-05-04T23:29:07Z

No, I don't think that's right - look at it more like a &(&mut T, Fn() -> T) - we need to be able to store the constructed T after calling the init function, so it mustnt return a supertype of T. We'd need to be able to do something clever with decoupling the return type of init from T.

// concretely,
let captured = 10u8;
let cell = LazyCell::new(|| &captured);
fn init_it<'a>(v: &'a (), cell: &'a LazyCell<&'a u8, impl FnOnce() -> &'a u8>) {
  &**cell; // call the function and store a `&'a u8` as the value
}
init_it(&(), &cell); // 'a is dead
let v: &u8 = &*a; // and when we access it, we've read it in 'b where not `'a: 'b`

In terms of your example, the &LazyCell<&'a i32, fn() -> &'a i32> would now be writing a &'a i32 to the target LazyCell<&'static i32, fn() -> &'static i32>, which is invalid.

(edit: oh and I should add that this doesn't create any problems w.r.t. Treed borrows itself afaik - the tagging is all still correct, but breaking the subtyping relationship on the lifetimes does create problems in the verification of borrowck as far as I understand it. someone might know better than me there 😁)

edit2: after discussing this on discord we realized that type erasing the function pointer on construction does the trick for "something clever with decoupling the return type of init from T". Neat, but obviously undesirable for the actual implementation

fn init_it<F: FnOnce() -> T>(f: *mut F, out: *mut T) {
    *out = (*f)()
}
fn LazyCell::new(f: impl FnOnce() -> T) {
    Uninit(f, init_it::<F> as fn(*mut (), *mut ()))
}
fn LazyCell::force() -> &T {
    (self.init_fn)(&mut self.f as *mut _ as *mut _, self.cell.as_mut_ptr() as *mut _ as *mut _)
    &self.cell
}

Using lazy_static is now discouraged as unmaintained and once_cell is the recommended replacement. On top of that a similar implementation found in once_cell is being tracked for inclusion under the `lazy_cell` feature gate [0] [0] rust-lang/rust#109736 Change-Id: I21d343a38dbd25bb2d13f239f7fa3a2d7f20323e

pitaj · 2024-05-21T22:08:11Z

For anyone following, this is your notice that #121377 (which will fully stabilize LazyCell and LazyLock as is) has entered the Final Comment Period.

tgross35 · 2024-05-21T22:58:50Z

Shouldn't LazyCell/LazyLock be also covariant over T? From a type system perspective, &LazyCell<T, F> is basically just a &(T, F) which dynamically chooses between calling F or returning a reference to T. This would e.g. allow using a &LazyCell<&'static i32, fn() -> &'static i32> where a &LazyCell<&'a i32, fn() -> &'a i32> was expected.

@joboet it was mentioned at #121377 (comment) that making the types covariant over F could be a future nonbreaking change. Is this also true over T?

Open question: - Do we want to wait for LazyLock? rust-lang/rust#109736

joboet · 2024-05-23T10:51:52Z

Shouldn't LazyCell/LazyLock be also covariant over T? From a type system perspective, &LazyCell<T, F> is basically just a &(T, F) which dynamically chooses between calling F or returning a reference to T. This would e.g. allow using a &LazyCell<&'static i32, fn() -> &'static i32> where a &LazyCell<&'a i32, fn() -> &'a i32> was expected.

@joboet it was mentioned at #121377 (comment) that making the types covariant over F could be a future nonbreaking change. Is this also true over T?

I don't understand why making it covariant over F would not be breaking; but I imagine the same rationale would apply for T...

Open question: - Do we want to wait for LazyLock? rust-lang/rust#109736

Rollup merge of rust-lang#121377 - pitaj:lazy_cell_fn_pointer, r=dtolnay Stabilize `LazyCell` and `LazyLock` Closes rust-lang#109736 This stabilizes the [`LazyLock`](https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html) and [`LazyCell`](https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html) types: ```rust 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

workingjubilee · 2024-05-27T16:25:52Z

We need a lazy_cell_consume tracking issue.

Using lazy_static is now discouraged as unmaintained and once_cell is the recommended replacement. On top of that a similar implementation found in once_cell is being tracked for inclusion under the `lazy_cell` feature gate [0] [0] rust-lang/rust#109736 Test: m Change-Id: I21d343a38dbd25bb2d13f239f7fa3a2d7f20323e Former-commit-id: 794a952642317f7da1be2ea69e6865c55ea37be6

Using lazy_static is now discouraged as unmaintained and once_cell is the recommended replacement. On top of that a similar implementation found in once_cell is being tracked for inclusion under the `lazy_cell` feature gate [0] [0] rust-lang/rust#109736 Test: m Change-Id: I21d343a38dbd25bb2d13f239f7fa3a2d7f20323e

This is to bypass: error[E0658]: use of unstable library feature 'lazy_cell' --> crates/omnix-init/src/config.rs:1:48 | 1 | use std::{collections::HashMap, path::PathBuf, sync::LazyLock}; | ^^^^^^^^^^^^^^ | = note: see issue #109736 <rust-lang/rust#109736> for more information = help: add `#![feature(lazy_cell)]` to the crate attributes to enable = note: this compiler was built on 2024-05-11; consider upgrading it if it is out of date

…s possible Since 1.80: rust-lang/rust#109736 and rust-lang/rust#98165 Non-Thread-Safe Lazy → std::cell::LazyCell https://doc.rust-lang.org/nightly/std/cell/struct.LazyCell.html Thread-safe SyncLazy → std::sync::LazyLock https://doc.rust-lang.org/nightly/std/sync/struct.LazyLock.html The compiler accepted LazyCell only in minilints. The final use in rslib/src/log.rs couldn't be replaced since get_or_try_init has not yet been standardized: rust-lang/rust#109737

… possible Since 1.80: rust-lang/rust#109736 and rust-lang/rust#98165 Non-Thread-Safe Lazy → std::cell::LazyCell https://doc.rust-lang.org/nightly/std/cell/struct.LazyCell.html Thread-safe SyncLazy → std::sync::LazyLock https://doc.rust-lang.org/nightly/std/sync/struct.LazyLock.html The compiler accepted LazyCell only in minilints. The final use in rslib/src/log.rs couldn't be replaced since get_or_try_init has not yet been standardized: rust-lang/rust#109737

* Anki: Replace lazy_static with once_cell Unify to once_cell, lazy_static's replacement. The latter in unmaintained. * Anki: Replace once_cell with stabilized LazyCell / LazyLock as far as possible Since 1.80: rust-lang/rust#109736 and rust-lang/rust#98165 Non-Thread-Safe Lazy → std::cell::LazyCell https://doc.rust-lang.org/nightly/std/cell/struct.LazyCell.html Thread-safe SyncLazy → std::sync::LazyLock https://doc.rust-lang.org/nightly/std/sync/struct.LazyLock.html The compiler accepted LazyCell only in minilints. The final use in rslib/src/log.rs couldn't be replaced since get_or_try_init has not yet been standardized: rust-lang/rust#109737 * Declare correct MSRV (dae) Some of our deps require newer Rust versions, so this was misleading. Updating the MSRV also allows us to use .inspect() on Option now

tgross35 added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Mar 29, 2023

tgross35 mentioned this issue Mar 29, 2023

Partial stabilization of once_cell #105587

Merged

This was referenced Mar 30, 2023

standard lazy types rust-lang/rfcs#2788

Merged

Tracking Issue for once_cell #74465

Closed

Keon6 mentioned this issue Apr 13, 2023

error[E0658]: use of unstable library feature 'lazy_cell' hashintel/hash#2408

Closed

remi-dupre added a commit to remi-dupre/gateway that referenced this issue Apr 13, 2023

fix(deps): remove dependency to lazy_static

e13aebb

once_cell supersets lazy_static features and its API is better and "soon" to be stabilized in the standard library: rust-lang/rust#109736

remi-dupre added a commit to remi-dupre/gateway that referenced this issue Apr 14, 2023

ARK-1 fix(deps): remove dependency to lazy_static

9ea1f0a

once_cell supersets lazy_static features and its API is better and "soon" to be stabilized in the standard library: rust-lang/rust#109736

Jeremiah-Griffin added a commit to Jeremiah-Griffin/TIFF_tags that referenced this issue Apr 18, 2023

change the feature flag for rustc issue #109736

e3ead33

rust-lang/rust#109736

netrome mentioned this issue May 15, 2024

Integrate Blocklist Client with Signer stacks-network/sbtc#154

Merged

caspermeijn added a commit to caspermeijn/prost that referenced this issue May 22, 2024

WIP: chore: Replace once_cell dependency by std lib

e3517c5

Open question: - Do we want to wait for LazyLock? rust-lang/rust#109736

caspermeijn added a commit to caspermeijn/prost that referenced this issue May 24, 2024

WIP: chore: Replace once_cell dependency by std lib

1fbbc33

Open question: - Do we want to wait for LazyLock? rust-lang/rust#109736

bors closed this as completed in 890982e May 26, 2024

seritools mentioned this issue May 26, 2024

Notes for future Rust version upgrades rust9x/rust#19

Open

1 task

tspiteri mentioned this issue May 27, 2024

Tracking Issue for lazy_cell_into_inner #125623

Open

3 tasks

cuviper mentioned this issue Jul 3, 2024

Insert into Indexmap randomly fails indexmap-rs/indexmap#330

Closed

chillinbythetree mentioned this issue Jul 30, 2024

error[E0658]: use of unstable library feature 'lazy_cell' Kl4rry/simp#41

Closed

aschaeffer mentioned this issue Sep 14, 2024

Migrate to Rust Stable reactive-graph/reactive-graph#102

Closed

4 tasks

nxtreaming mentioned this issue Oct 1, 2024

Fail to compile the latest code erebe/wstunnel#363

Closed

apraga mentioned this issue Oct 10, 2024

cargo installs fails to build (unstable feature lazy_cell) Cretezy/lazyjj#64

Closed

Voim4 mentioned this issue Oct 24, 2024

bug: Vdash installation stops with "error[E0658]: use of unstable library feature 'lazy_cell'" happybeing/vdash#33

Closed

lecheel mentioned this issue Nov 15, 2024

[BUG] can not successful build on 1.75 waylyrics/waylyrics#274

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `lazy_cell` #109736

Tracking Issue for `lazy_cell` #109736

tgross35 commented Mar 29, 2023 •

edited by pitaj

Loading

tgross35 commented Mar 29, 2023

matklad commented Mar 29, 2023

tgross35 commented Mar 29, 2023

Sp00ph commented Mar 30, 2023

tgross35 commented Mar 30, 2023 •

edited

Loading

Sp00ph commented Mar 30, 2023

SUPERCILEX commented Mar 30, 2023

tgross35 commented Mar 30, 2023

tgross35 commented Mar 30, 2023

bstrie commented Mar 30, 2023

NobodyXu commented Mar 31, 2023 •

edited

Loading

tgross35 commented Mar 31, 2023 •

edited

Loading

NobodyXu commented Mar 31, 2023

matklad commented Apr 2, 2023

tgross35 commented Apr 3, 2023

bjorn3 commented Apr 3, 2023

tgross35 commented Apr 3, 2023

slanterns commented Apr 3, 2023

tgross35 commented Apr 3, 2023

nbdd0121 commented Apr 6, 2023

SUPERCILEX commented Apr 24, 2023

joboet commented May 4, 2024

Plecra commented May 4, 2024 •

edited

Loading

pitaj commented May 21, 2024

tgross35 commented May 21, 2024

joboet commented May 23, 2024

workingjubilee commented May 27, 2024

Tracking Issue for lazy_cell #109736

Tracking Issue for lazy_cell #109736

Comments

tgross35 commented Mar 29, 2023 • edited by pitaj Loading

Public API

Steps / History

Unresolved Questions

Footnotes

tgross35 commented Mar 29, 2023

matklad commented Mar 29, 2023

tgross35 commented Mar 29, 2023

Sp00ph commented Mar 30, 2023

tgross35 commented Mar 30, 2023 • edited Loading

Sp00ph commented Mar 30, 2023

SUPERCILEX commented Mar 30, 2023

tgross35 commented Mar 30, 2023

tgross35 commented Mar 30, 2023

bstrie commented Mar 30, 2023

NobodyXu commented Mar 31, 2023 • edited Loading

tgross35 commented Mar 31, 2023 • edited Loading

NobodyXu commented Mar 31, 2023

matklad commented Apr 2, 2023

tgross35 commented Apr 3, 2023

bjorn3 commented Apr 3, 2023

tgross35 commented Apr 3, 2023

slanterns commented Apr 3, 2023

tgross35 commented Apr 3, 2023

nbdd0121 commented Apr 6, 2023

SUPERCILEX commented Apr 24, 2023

joboet commented May 4, 2024

Plecra commented May 4, 2024 • edited Loading

pitaj commented May 21, 2024

tgross35 commented May 21, 2024

joboet commented May 23, 2024

workingjubilee commented May 27, 2024

Tracking Issue for `lazy_cell` #109736

Tracking Issue for `lazy_cell` #109736

tgross35 commented Mar 29, 2023 •

edited by pitaj

Loading

tgross35 commented Mar 30, 2023 •

edited

Loading

NobodyXu commented Mar 31, 2023 •

edited

Loading

tgross35 commented Mar 31, 2023 •

edited

Loading

Plecra commented May 4, 2024 •

edited

Loading