Implement #[async_send] attribute for async fns

[eholk]

This gives a potential solution for the spawning from generics issue with async functions in traits. The goal here is to make something that users can experiment with and provide feedback on, but this is not intended to be the final syntax or even final design.

r? @compiler-errors

cc @rust-lang/wg-async

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[compiler-errors]

This needs several test, both for functionality and for the feature gate (proving that adding this attribute requires enabling a feature gate)

[eholk]

This needs a test, both for functionality and for the feature gate (proving that adding this attribute requires enabling a feature gate)

Oh, d'oh! I forgot to add the file with my functional test. I need to add one for the feature gate too though.

[compiler-errors]

is this needed?

[eholk]

The true definitely isn't! (Sorry, that was left over from by debugging attempts).

The async_fn_in_trait check is probably not needed either since you can't even type this attribute without it. I'll try and remove it.

[eholk]

@rustbot author

[eholk]

@rustbot ready

[compiler-errors]

The implementation looks fine to me, though I was curious if there was some support from @rust-lang/wg-async or @rust-lang/lang for adding this. I was unsure if this was the direction that we wanted to go with adding support for Send, etc. to futures.

[eholk]

I'd also love to hear other opinions from @rust-lang/wg-async. I did talk with @yoshuawuyts about this idea earlier this week and he seemed supportive of it, although mostly for experimentation and not as the final version.

As for me, I'll admit I don't particularly like this solution. I'd rather land on something like async<Send> fn foo(), but I think it's not too hard to go from this PR to something like that. I like the idea of merging this sooner though so there's something in nightly that people can play around with.

I think this question of Send bounds on async methods is something we should sort out before stabilizing AFIT, so the sooner we can get experience with solutions and start iterating on them the better.

[nrc]

I think this is fine for experimentation. I think we'll want other syntax in the future, but for now, this is fine.

[eholk]

Based on some of the objections raised by @Dirbaio in the Zulip thread, I'm kind of inclined to hold off on merging this for now. There's not really any harm in merging it for experimentation, but if we aren't confident that this or something like it is something we'll want long term, there's not a lot of point in merging something that we'll have to remove later.

[compiler-errors]

Gonna mark this as S-blocked for now then.

@rustbot blocked

[bors]

☔ The latest upstream changes (presumably #111169) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

I'm gonna close this since it's gone somewhat stale, and I'm not sure if this is the approach we're looking at experimenting with anymore...

Obviously this doesn't delete the branch or anything so please feel free to reopen a new PR and request review from me if wg-async does decide that this is worth landing experimentally...