Skip to content

Document auto trait inference for async blocks #1093

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.

Sign up for GitHub

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Document auto trait inference for async blocks #1093

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4b35388
Document auto trait inference for async blocks
eholk Sep 29, 2021
00fce4a
Fix tests
eholk Sep 29, 2021
5a0856c
Merge branch 'master' of https://github.com/rust-lang/reference into …
eholk Oct 20, 2021
b33a14e
Add positive and negative examples to try to make the behavior more c…
eholk Oct 20, 2021
734fc47
Trim trailing whitespace
eholk Oct 20, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions src/expressions/block-expr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,24 @@ loop {
}
```

### Auto traits and `async` blocks

Auto trait inference for `async` blocks follow the same [rules as closures] except that [temporary values that are in scope][temporary-scopes] at an `await` expression are also considered. For example, consider the following block:

```rust
# fn bar() -> i32 { 42 }
# async fn foo() {}
async {
match bar() {
_ => foo().await,
}
}
# ;
```

Here the result of `bar()` is in scope during the await of `foo()`, so the result of `bar()` will impact the inferred auto traits.
Copy link
Member

@pnkfelix pnkfelix Oct 19, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The phrase "during the await of foo()" might be ambiguous, depending on what other assumptions the reader is making.

I guess my concern is about some scenario where you have an EXPR.await, and the temporary scope of some baz() is entirely contained within the EXPR, and does not overlap the .await operator itself.

(I will see if I can construct an illustrative example.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed "during" to "for," but I don't think that really addresses your concern...

A couple of examples that might be relevant here could be something like foo().bar().await, and { let bar = foo().bar(); bar }.await. I'll have to experiment some more, but I think what happens here is that foo() is borrowed across the away in the first example, but not the second.

If `bar()` is not `Send`, then the future for the whole match block will also not be `Send`.

## `unsafe` blocks

> **<sup>Syntax</sup>**\
Expand Down Expand Up @@ -189,3 +207,5 @@ fn is_unix_platform() -> bool {
[tuple expressions]: tuple-expr.md
[unsafe operations]: ../unsafety.md
[value expressions]: ../expressions.md#place-expressions-and-value-expressions
[rules as closures]: ../special-types-and-traits.md#auto-traits
[temporary-scopes]: ../destructors.md#temporary-scopes