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.

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

Jump to bottom

Prevent await from creating a generator #51719

Closed
cramertj opened this issue Jun 22, 2018 · 8 comments · Fixed by #60586
Closed

Prevent await from creating a generator #51719

cramertj opened this issue Jun 22, 2018 · 8 comments · Fixed by #60586
Labels
AsyncAwait-Polish Async-await issues that are part of the "polish" area T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cramertj
Copy link
Member

The await macro implemented in #51580 can be abused to create a generator (e.g. || await!()). This shouldn't be allowed.
@cramertj cramertj mentioned this issue Jun 22, 2018
Merged
@eddyb eddyb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 22, 2018
@withoutboats withoutboats mentioned this issue Jun 22, 2018
Closed
11 tasks
@eddyb eddyb mentioned this issue Jun 24, 2018
Closed
@BatmanAoD
Copy link
Member

Is there an explanation somewhere of why this is necessarily bad?

@cramertj
Copy link
Member Author

@BatmanAoD The fact that await!() internally uses yield is an implementation detail which shouldn't be exposed to end users. Eventually we'd like to be able to use async generators (where both yield and await are valid and mean very different things) in order to write Streams.

@BatmanAoD
Copy link
Member

BatmanAoD commented Jul 11, 2018 •
edited
Loading

Ah, okay.

Is there any compelling reason to permit await! inside a closure at all, with any semantics?

@cramertj
Copy link
Member Author

cramertj commented Jul 11, 2018 •
edited
Loading

@BatmanAoD Non-async closures? No. await shouldn't be allowed outside of async closures, blocks, and functions.

@BatmanAoD
Copy link
Member

Oh, I didn't notic that the async/await RFC permitted specifying that a closure could be async. Yes, I meant non-async closures.

Inside of async closures, permitting await! as-is shouldn't really be a problem, right?

@tmandry
Copy link
Member

tmandry commented Mar 13, 2019

Should this be tagged as AsyncAwait-Blocker?

@cramertj
Copy link
Member Author

Yup!

@cramertj cramertj added the AsyncAwait-Polish Async-await issues that are part of the "polish" area label Mar 13, 2019
@cramertj
Copy link
Member Author

(but it's also in the group of issues that would be obviously fixed by native syntax)

@cramertj cramertj mentioned this issue Apr 25, 2019
Closed
@cramertj cramertj mentioned this issue May 6, 2019
Merged
bors added a commit that referenced this issue May 7, 2019
@bors
Auto merge of #60586 - cramertj:await, r=oli-obk
33cde4a 
Implement built-in await syntax

Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.

This new syntax is not final, but is the consensus solution proposed by the lang team, as explained in https://boats.gitlab.io/blog/post/await-decision/

Fix #51719
Fix #51751
Fix #60016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
AsyncAwait-Polish Async-await issues that are part of the "polish" area T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Implement built-in await syntax cramertj/rust
4 participants
@eddyb @tmandry @BatmanAoD @cramertj