Add support for either

[the10thWiz]

Along the way, I discovered a case where the current trait logic doesn't quite work.

[the10thWiz]

@JRRudy1 Hey, just wanted to ask if you're able to take a look at this PR.

Also, given the importance of this library to Rocket, us at RWF2 are interested in adopting it. We don't want to just take it away, but we would prefer to avoid forking it in the future to get the implementations and features we need. We also want to proactively prevent transient from becoming abandoned.

[JRRudy1]

Hey Matthew, sorry I have been on vacation without computer access the past 2 weeks and wasn't able to address this. I am reviewing it now and will merge shortly.

As for RFW2 "adopting" the crate, what exactly would that look like? I didn't plan to abandon it anytime soon, and even if that ever were to happen the permissive license would let you freely fork/incorporate it into Rocket as needed. And if transient is going to be an implementation detail for Rocket, then the change would be transparent to users. I can also add you as a maintainer for the repo, honestly I thought I already had.

[JRRudy1]

This looks good to me! If you can just remove the commented-out example (assuming you agree with my assessment of it), then I will go ahead and merge.

[JRRudy1]

@the10thWiz I removed the comment and tweaked one other thing, so I will go ahead and merge now. Thanks for the contribution!

[the10thWiz]

@JRRudy1 For the example - if adding the function pointer impl solved it, I'm more than happy with just removing it. I don't know if we can easily provide an impl for function pointers (they are kind of weird with trait implementations, so we can't easily provide implementations for fn pointers with different numbers of arguments). At the same time, I don't think there is significant value to upcasting function pointers to Any, so I'm happy with just requiring users to create a struct to hold it.

For adopting - I can't 100% say what adopting the crate will look like, but it's mostly intended to be an insurance thing. Although you may not be intending to abandon this crate, things outside our control happen all the time. In fact, this nearly happened to Rocket - @SergioBenitez wound up mostly abandoning Rocket for almost 4 years. That was the impetus to create rwf2, so that if he has to step away from the project again, I (or other members of the org), can continue to release updates and improvements. Having push access (and maybe access to push new versions to crates.io) is more than enough. The main thing is, we don't want to have to fork this project, and leave an unmaintained crate floating in the Rust ecosystem.

That being said, if you are interested, feel free to reach out to @SergioBenitez, he can provide more in-depth options.

[JRRudy1]

At the same time, I don't think there is significant value to upcasting function pointers to Any, so I'm happy with just requiring users to create a struct to hold it.

I agree that erasing function pointers isn't particularly meaningful on its own, but adding the impls would be still be useful for examples like yours where a function pointer appears as a generic argument on another type like Either.

I don't know if we can easily provide an impl for function pointers (they are kind of weird with trait implementations, so we can't easily provide implementations for fn pointers with different numbers of arguments

While it isn't really possible to support function pointers with an arbitrary number of arguments, we could add least use macro_rules to support a limited number. I just merged PR #14 increasing the max tuple length from 4 to 5, and later today I'll submit a PR adding impls for fn pointers with 0-4 arguments, which should cover the vast majority of cases.

[the10thWiz]

While it isn't really possible to support function pointers with an arbitrary number of arguments, we could add least use macro_rules to support a limited number.

That's right. I was thinking of trying to implement something for T: Fn(...), in which case you actually can't even do a limited number of overloads, since Rust believes you can implement both Fn(A) and Fn(A, B).