google
Allow futures on Serve and Stub to be Send
This looks like a reasonable change to me.
Perfect, that's what I was looking for by putting up an early draft.
Doesn't Serve need to be made a trait variant, too?
Probably, was just focusing on my use case a little too much 😅
Also, could you add some tests demonstrating how it will work for users?
Will do, as I mentioned this is an early draft to make sure the change makes sense.
Haven't forgotten, just wrapped up in other stuff. I'll try to get to it soon!
Looks like trait_variant::make doesn't support default implementations in trait definitions. I could update the macro in that crate, thoughts?
Also, how do you feel about renaming Serve and Stub to LocalServe and LocalStub so that the "default" type is Send, seems like the more common use case potentially.
I've given it some more thought and I'm wondering if the right move is to instead have a feature flag that annotates all traits with async methods in them with async_trait. Thoughts @tikue?
I also just saw https://github.com/rust-lang/rfcs/pull/3654. Wonder how long it will take to be available on nightly?
I also just saw rust-lang/rfcs#3654. Wonder how long it will take to be available on nightly?
Looks like even post-implementation the RFC still recommends the pattern provided by trait_variant: https://github.com/nikomatsakis/rfcs/blob/rtn/text/0000-return-type-notation.md#rtn-supports-convenient-trait-aliases
https://github.com/nikomatsakis/rfcs/blob/rtn/text/0000-return-type-notation.md#guidelines-and-best-practices
Sorry for ping, any updates?
I'm currently using my fork's branch trait-variant and it seems to work fine. Probably that could be merged soon since it is backwards compatible with the old way, as it only adds Tokio* types that bound the futures to be Send.