There's no need to have the box_futures, use_associated_futures, etc things anymore now that Rust natively supports async fn in traits. Those features also made the library much more complicated.
The only reason to box futures in Rust that I can think of is in the case of dynamic dispatch, and the go-to solution for that is still #[async_trait].
Entrait 0.7 will instead have interoperability with the async_trait macro, and users will explicitly use that instead of passing a "magic keyword" into the entrait macro.
async Send-ness
How to approach Send bounds on Future is a recurring debate in the development of the Rust language. async_trait made a design decision to make all futures Send by default, with an opt-out available via #[async_trait(?Send)]. I think entrait will take a similar approach, i.e. #[entrait(SomeTrait, ?Send)] will make any async fn in the generated trait opt out of the Send bound. I don't think this should be made automatic via features, because it changes the behaviour instead of being additive.
unimock upgrade
This entrait version will depend on unimock 0.6, which contains important fixes related to mutable references in function arguments.
async rework
There's no need to have the
box_futures,use_associated_futures, etc things anymore now that Rust natively supports async fn in traits. Those features also made the library much more complicated.The only reason to box futures in Rust that I can think of is in the case of dynamic dispatch, and the go-to solution for that is still
#[async_trait]. Entrait 0.7 will instead have interoperability with theasync_traitmacro, and users will explicitly use that instead of passing a "magic keyword" into the entrait macro.async Send-ness
How to approach
Sendbounds onFutureis a recurring debate in the development of the Rust language.async_traitmade a design decision to make all futuresSendby default, with an opt-out available via#[async_trait(?Send)]. I think entrait will take a similar approach, i.e.#[entrait(SomeTrait, ?Send)]will make anyasync fnin the generated trait opt out of theSendbound. I don't think this should be made automatic via features, because it changes the behaviour instead of being additive.unimock upgrade
This entrait version will depend on unimock 0.6, which contains important fixes related to mutable references in function arguments.