RFC: Return type notation

[tmandry]

This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap

[Noah-Kennedy]

Could you add a description here?

[tmandry]

Draft is in https://hackmd.io/KJaC_dhZTmyR_Ja9ghdZvg

[punkeel]

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 need Send 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 👍