Open ShaneMurphy2 opened 3 months ago
Sorry for the delay in reviewing! Will try to look in the next week.
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.
I'll get back to this in a day or so, thanks for the review!
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
Not sure if this approach is the right one, so this MR is a draft.