Allow futures on Serve and Stub to be Send

[ShaneMurphy2]

Not sure if this approach is the right one, so this MR is a draft.

[tikue]

Sorry for the delay in reviewing! Will try to look in the next week.

[tikue]

This looks like a reasonable change to me. Doesn't Serve need to be made a trait variant, too? Also, could you add some tests demonstrating how it will work for users?

[tikue]

Nit: typo

Suggested change

	/// A [`Stub`] implementation that simply warps a `Serve`.
	/// A [`Stub`] implementation that simply wraps a `Serve`.

[tikue]

Maybe keep this type private for now and return an imp Stub? Can always make it public later if needed.

[ShaneMurphy2]

Good idea

[ShaneMurphy2]

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.

[ShaneMurphy2]

I'll get back to this in a day or so, thanks for the review!

[ShaneMurphy2]

Haven't forgotten, just wrapped up in other stuff. I'll try to get to it soon!

[ShaneMurphy2]

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.

[ShaneMurphy2]

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?