google
Do we need custom return type specification?
From my experience Pin+Box+dyn Future is the only stable solution anyway when writing logic in the server handlers. And with async/await type erasure becomes pretty much mandatory.
I see the benefit of the simple case of returning boxed futures. On the other hand, I really like not baking in assumptions about how people use it. It's nice that one can impl a future by hand if they want.
How about a meta item that enables boxing? e.g. #[tarpc::service(box_futures = true)]?
It is a good solution. I would make boxing default though, as it will be the most popular use case. Another option is the feature flag which would open associated types for modification when enabled and always box if disabled.
I'd prefer not a feature flag, because it doesn't allow mixing both kinds of services in a single crate. Also, I think feature flags are only supposed to enable new features rather than change existing behavior?