Tracking Issue for arc_new_cyclic

[KodrAus]

The feature gate for the issue is #![feature(arc_new_cyclic)].

Tracking the following API:

impl<T> Arc<T> {
    pub fn new_cyclic(data_fn: impl FnOnce(&Weak<T>) -> T) -> Arc<T>;
}

impl<T> Rc<T> {
    pub fn new_cyclic(data_fn: impl FnOnce(&Weak<T>) -> T) -> Rc<T>;
}

Steps

• Add Arc::new_with() function for constructing self-referential data structures #72443
• Implement Arc::new_cyclic (Add Arc::new_cyclic #75505)
• Implement Rc::new_cyclic (impl Rc::new_cyclic #75994)
• FCP: Stabilize arc_new_cyclic #90666 (comment)
• Stabilization PR: Stabilize arc_new_cyclic #90666

Unresolved Questions

[mental32]

@Dylan-DPC @KodrAus allow me a day to implement arc_new_cyclic on Rc :)

[eduardosm]

I think "Implement Rc::new_cyclic" can be marked as done.

[ObsidianMinor]

Is there a specific reason why the definitions of Arc::new_cyclic and Rc::new_cyclic use impl FnOnce instead of an explicit generic type?

[Thomasdezeeuw]

I need a version of Arc::new_cyclic where the creation function can fail, would such a function be acceptable? Or should I open another issue for that?

The API would look something like the following:

impl<T> Arc<T> {
    pub fn try_new_cyclic<F, E>(data_fn: F) -> T) -> Result<Arc<T>, E>
    where
        F: FnOnce(&Weak<T>) -> Result<T, E>,
    {
        // ...
    }
}

[philip-peterson]

It would be nice to have multiple arities of this function, i.e.

fn new_cyclic_2<A, B>(data_fn: impl FnOnce(&Weak<A>, &Weak<B>) -> (A, B)) -> (Arc<A>, Arc<B>) {
 ...
}

and ditto for 3, etc. The use case would be for when your type B also contains a Weak<A> and/or vice-versa.

[philip-peterson]

@Johannesd3 Thanks for that, it's a lot cleaner than what I got from experimenting myself.

One thing I noticed when testing it though is that there is a bug with arc_new_cyclic as far as I can tell. The docs state:

Attempting to upgrade the weak reference before this function returns will result in a None value.

To me this implies that after the function returns, it will be safe. (I know that's not technically what it says, but...) also:

the weak reference may be cloned freely and stored for use at a later time.

When putting this to test, the upgrade fails:

#[test]
fn arc_new_cyclic_deferred_upgrades_succeed() {
    let mut foo = None;
    Arc::new_cyclic(|weak_a| {
        foo = Some(weak_a.clone());

        (1,)
    });
    assert_eq!(*foo.unwrap().upgrade().unwrap(), (1,));
}

failures:

---- tests::arc_new_cyclic_deferred_upgrades_succeed stdout ----
thread 'tests::arc_new_cyclic_deferred_upgrades_succeed' panicked at 'called `Option::unwrap()` on a `None` value', src/lib.rs:17:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ogoffart]

@philip-peterson That's because you did not keep the Arc alive, so it is destroyed after the function call. fix it by assigning the resulting Arc to some value: let arc = Arc::new_cyclic( ...

[philip-peterson]

@ogoffart ah, thank you!!

I created a third party crate to house the multi-arity versions of new_cyclic at https://github.com/philip-peterson/arc_new_cyclic_n -- @Johannesd3 thank you for your help on this, please let me know if you have any disagreements with this crate existing.

[tmandry]

Are additional docs required for this feature? The documentation in std looks sufficient. The rustc guide says the reference must be updated, but I'm pretty sure that doesn't apply to library APIs.

The unstable book has a stub entry, that might need a blurb on the feature but I'm not sure it matters for stabilization.

Are there any other blockers for stabilization?

[chris-laplante]

I need a version of Arc::new_cyclic where the creation function can fail, would such a function be acceptable? Or should I open another issue for that?

With assistance from the Forum, I found that implementing try_new_cyclic appears pretty simple: https://users.rust-lang.org/t/implementing-an-rc-try-new-cyclic/62945. To echo @Thomasdezeeuw, should I submit a new issue / pull request for it?

[bdbai]

@chris-laplante try_* functions in Arc are related to allocators. Shall we pick another name?

[chris-laplante]

@chris-laplante try_* functions in Arc are related to allocators. Shall we pick another name?

How about new_cyclic_fallible?

[dtolnay]

What's a real world use case for try_new_cyclic where the fallible work can't be done before the new_cyclic call, possibly putting Weak::new() placeholders into the object? That way new_cyclic only needs to wire in the self references into an exclusively owned object.

let mut obj = try_obj()?;
let rc = Rc::new_cyclic(move |this| {
    obj.this = Weak::clone(this);
    obj
});

[Thomasdezeeuw]

@dtolnay I have a use case where a fallible Arc::new_cyclic would help, although I'm currently working around with an additional type. Basically I need to make a system call (the fallible part) to create a special fd (epoll in this case), which I then put in a shared structure (using an Arc). But this shared structure contains a type (waker_id, see code below) which is created using an Arc reference to the shared structure itself. But like I said I'm working around with an additional type, so it's a livable workaround.

The code is available here:
https://github.com/Thomasdezeeuw/heph/blob/aa6ccf79de85c0abccb6a26f920c7d9d405e80cf/src/rt/coordinator.rs#L103-L107

With the call to setup:
https://github.com/Thomasdezeeuw/heph/blob/aa6ccf79de85c0abccb6a26f920c7d9d405e80cf/src/rt/shared/mod.rs#L108-L113

And the intermediate type:
https://github.com/Thomasdezeeuw/heph/blob/aa6ccf79de85c0abccb6a26f920c7d9d405e80cf/src/rt/shared/mod.rs#L33-L46

[ckaran]

How close is this to stabilization?

[m-ou-se]

How close is this to stabilization?

Very close! The FCP just finished and I approved the stabilization PR just now. It'll be stable in Rust 1.60.0.