Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Return type notation #290

Open
Tracked by #279 ...
tmandry opened this issue Mar 7, 2023 · 3 comments
Open
Tracked by #279 ...

RFC: Return type notation #290

tmandry opened this issue Mar 7, 2023 · 3 comments
Assignees
Labels
roadmap-topic Top-line goal for the roadmap

Comments

@tmandry
Copy link
Member

tmandry commented Mar 7, 2023

This is a roadmap item for wg-async. You can view the roadmap here: https://github.com/orgs/rust-lang/projects/28

@tmandry tmandry added this to the Async 2023 milestone Mar 7, 2023
@tmandry tmandry added the roadmap-topic Top-line goal for the roadmap label Mar 7, 2023
@Noah-Kennedy
Copy link

Could you add a description here?

@tmandry tmandry removed the roadmap-topic Top-line goal for the roadmap label Mar 9, 2023
@tmandry tmandry mentioned this issue Mar 13, 2023
3 tasks
@tmandry tmandry assigned eholk and unassigned nikomatsakis Mar 23, 2023
@tmandry
Copy link
Member Author

tmandry commented Mar 23, 2023

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

@punkeel
Copy link
Contributor

punkeel commented Jun 23, 2023

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 👍

@traviscross traviscross added the roadmap-topic Top-line goal for the roadmap label Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap-topic Top-line goal for the roadmap
Projects
Status: No status
Development

No branches or pull requests

6 participants