ACP: Implement `Fn` traits for `Rc` and `Arc`

[nvzqz]

Proposal

Problem statement

It is not possible to pass reference-counted closures to APIs that take Fn + 'static or Fn + Clone.

Motivation, use-cases

Many server APIs expect 'static lifetimes but some logic may be implemented in a single closure that's reused in other places. Currently this would require moving captured values and invoking Clone on the closure itself, which clones captured values.

Solution sketches

impl<A, F: Fn<A> + ?Sized> Fn<A> for Rc<F>
impl<A, F: Fn<A> + ?Sized> FnMut<A> for Rc<F>
impl<A, F: Fn<A> + ?Sized> FnOnce<A> for Rc<F>

impl<A, F: Fn<A> + ?Sized> Fn<A> for Arc<F>
impl<A, F: Fn<A> + ?Sized> FnMut<A> for Arc<F>
impl<A, F: Fn<A> + ?Sized> FnOnce<A> for Arc<F>

Alternative solutions: none.

Links and related work

Implementation: rust-lang/rust#105414

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[nvzqz]

It seems this may be a breaking change without specialization https://github.com/rust-lang/rust/actions/runs/3636798670/jobs/6137112313#step:26:606. 😞

[marmeladema]

Already requested and rejected at least twice in the past:

• Implement Fn traits for Rc and Arc rust#71570
• Add Fn impl to Arc rust#89771

[nvzqz]

Thanks for the links. I guess we can add this to the Rust 2.0 bucket list.

[marmeladema]

To be fair, the ACP process did not exist at the time. Maybe it's a good place to start gathering legitimate use cases and potential breaking concerns? There are some but scattered in the different PRs.
It seems to me that if different people regularly need this, it's a change that should at least be considered by the libs-team and maybe shipped in edition 2024?

[nvzqz]

I don't see how an edition change can fix this unless specialization is stabilized and made automatic.

[marmeladema]

I think the others attempts were not facing issues with specialization but rather with #[fundamental].
I personally think it's up to the libs-team to give an answer whether such a change is worth introducing in the next edition.