You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quick comment regarding Why not make all futures send?. First time commenting a Rust RFC, so apologies if this isn't the right place to share this (it wouldn't fit in a hackmd comment :)).
I think the question "Why not put send bounds on the trait?" (as suggested in the comment) is a better one, for the following reasons.
async_trait does it, and users will want to migrate to the stable async trait features when it becomes available. This section will be the go-to place (at least, at first) to understand why it doesn't work the same way.
Traits define a contract, function signatures define a contract. These two concepts seem similar enough that users will be confused?
May I propose looking at this question from the perspective of different personas?
Async runtime makers want (...). (I don't know)
Library authors want to hide the complexity from their users.
End users want simple code (ie: simple traits and simple function signatures), and are fine with some trade-offs that are not acceptable for library authors. Making every trait Send might be fine for them? (Another example of this: code written with std not being portable to no_std)
Work-stealing async runtime users needSend types, and so (..). Single threaded async-runtime users can use both Send and !Send, but don't want to be restricted to Send when implementing types, etc.. (aka: could we make all futures Send, with an escape hatch?)
I'm not sure RTN "wins" for these last 2 points, compared to Send-bound traits
Could we have both RTN and Send-bound traits? Is this a bad idea/impossible?
Maybe some of these could be mentioned in Drawbacks. My point is mostly that I believe this question to be important, and the first place people will read 👍
This is a roadmap item for wg-async. You can view the roadmap here: https://github.com/orgs/rust-lang/projects/28
The text was updated successfully, but these errors were encountered: