Add Fn impl to Arc

[bsodmike]

This commit refers to the discussion in #89727

Please let me know if any further improvements are needed :)

Thanks!

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

[marmeladema]

I think this would be a valuable addition to rust, however it has been tried and rejected in the past: #71570

But maybe the situation changed since?

[bsodmike]

Just checking if the test in #71570 works for my changes. Feel free to close this PR due to historical/breaking changes.

[Mark-Simulacrum]

The previous PR was closed because the presented motivation did not feel strong enough to override the desire to avoid breaking changes, particularly ones judged major by accepted policy. Do you have a motivating example for this? If this is just motivated by a desire to clean up and inconsistency, then I think we can just close this PR, that is insufficient IMO to motivate overriding the breaking change concern.

[marmeladema]

My personal use case is that i'd like to have a trait with an associated types that must implement Fn and I want the implementors of the trait to be able to return an Arc<dyn Fn> or a Rc<dyn Fn> depending on if they need thread safety or not etc without requiring boxing a new closure each time.

This is a contrived example of what I would to be able to do:

use std::sync::Arc;

trait GenFn {
    type Output: Fn() -> String;
    
    fn gen(&mut self) -> Self::Output;
}

struct FnBuilder;

impl GenFn for FnBuilder {
    type Output = Arc<dyn Fn() -> String>;
    
    fn gen(&mut self) -> Self::Output {
        Arc::new(|| "Hello World!".to_string())
    }
}

Play link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bdf2d5e5e1526542219cc29927f1970a

[ollpu]

Was there discussion about adding the corresponding impls for Box being a breaking change (merged in #59500) by the same token? Of course, the Box impls are arguably more useful, but I wonder if it was overlooked back then or what the arguments were. Unfortunate situation in any case.

[JohnCSimon]

Ping from triage:
@bsodmike - Can you post your status on this PR?

[Others]

I think these missing implementations are a minor language wart, and we should fix them somehow.

Is it possible to get a crater run for the PR to see if this theoretical breakage exists in practice?

I'm happy to rebase this if the original owner is unavailable.

[Mark-Simulacrum]

Following up on this (I missed #89771 (comment) in my notifications) now -- it is somewhat unfortunate these impls do not exist, but I don't think the presented motivation is sufficiently strong to override the breaking change concern (which crater cannot really resolve).

The specific pattern mentioned is fairly rare (bounding an associated type with Fn) and substituting a user-defined trait, perhaps one deref'ing to Fn, should work I think.

[Dylan-DPC]

Closing this based on #89771 (comment)