Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 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 onFuture
is a recurring debate in the development of the Rust language.async_trait
made a design decision to make all futuresSend
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 anyasync fn
in the generated trait opt out of theSend
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.