Not planned
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Fn
traits forRc
andArc
rust-lang/rust#105414[-]Implement `Fn` traits for `Rc` and `Arc`[/-][+]ACP: Implement `Fn` traits for `Rc` and `Arc`[/+]nvzqz commentedon Dec 7, 2022
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 commentedon Dec 7, 2022
Already requested and rejected at least twice in the past:
nvzqz commentedon Dec 7, 2022
Thanks for the links. I guess we can add this to the Rust 2.0 bucket list.
marmeladema commentedon Dec 7, 2022
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 commentedon Dec 7, 2022
I don't see how an edition change can fix this unless specialization is stabilized and made automatic.
marmeladema commentedon Dec 7, 2022
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.