Closed ebkalderon closed 2 years ago
After a bit more investigation, I believe this might indirectly be caused by https://github.com/rust-lang/rust/issues/64552, the same rustc
bug that caused #141. Attempting to reduce this example any further runs into similar error messages quite a lot.
EDIT: My example seems strikingly similar to https://github.com/rust-lang/rust/issues/64552#issuecomment-666084589.
Interestingly, this simplified example actually works as expected: Playground link
As soon as I try to use higher-kinded lifetimes and wrap the receiver in an Arc
, then the lifetimes refuse to match up.
A temporary workaround I've found is to wrap the trait method in a regular async fn
like so:
async fn my_handler<T: MyHandlers>(receiver: &T) -> Result<(), ()> {
receiver.my_handler(arg).await
}
router.define_method("my_handler", my_handler); // This works!
I'm glad you found a workaround. I am going to close this issue in favor of https://github.com/rust-lang/rust/issues/64552, since I believe this is a compiler bug.
I'm running into the following apparent edge case with
async-trait
where a generic trait is being implemented for inherentasync fn
instance methods, but not onasync-trait
instance methods:See the playground link for the minimal reproducible example.
It seems odd that the
Handler
trait isn't being implemented for methods generated byasync-trait
. I believe the included blanketimpl
s should cover methods returningimpl Future<Output = _>> + Send
andPin<Box<dyn Future<Output = _> + Send>>
equally. Any ideas why this could be?Might be related to #47, but I'm not sure. That issue is more about implementing an
async-trait
on top of anyFn() -> Fut
, while this issue is getting a regular trait to apply equally to both inherentasync fn
andasync-trait
methods, but there could possibly be some overlap.