Skip to content

Editorial cleanup on expressions (part 1) #967

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

Merged
merged 4 commits into from
Mar 28, 2021
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
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
Prev Previous commit
Apply suggestions from code review
Co-authored-by: Eric Huss <eric@huss.org>
  • Loading branch information
Havvy and ehuss committed Mar 25, 2021
commit 23672971a16c69ea894bef24992b74912cfe5d25
2 changes: 1 addition & 1 deletion src/expressions/await-expr.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
> &nbsp;&nbsp; [_Expression_] `.` `await`

*Await expressions* suspend the current computation until the given future is ready to produce a value.
The syntax for an await expression is an expression with a type that implements the Future trait, called the *future operand*, then the token `.`, and then the `await` keyword.
The syntax for an await expression is an expression with a type that implements the [Future] trait, called the *future operand*, then the token `.`, and then the `await` keyword.
Await expressions are legal only within an [async context], like an [`async fn`] or an [`async` block].

More specifically, an await expression has the following effect.
Expand Down
1 change: 1 addition & 0 deletions src/expressions/block-expr.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@ Statements are usually required to be followed by a semicolon, with two exceptio

1. Item declaration statements do not need to be followed by a semicolon.
2. Expression statements usually require a following semicolon except if its outer expression is a flow control expression.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think there should be a blank like after this, so that the sentence "Furthermore, extra semicolons..." is not combined with the last point. At least, the way I'm reading it, it doesn't seem like it should be combined.


Furthermore, extra semicolons between statements are allowed, but these semicolons do not affect semantics.

When evaluating a block expression, each statement, except for item declaration statements, is executed sequentially.
Expand Down
2 changes: 1 addition & 1 deletion src/expressions/field-expr.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
A *field expression* is a [place expression] that evaluates to the location of a field of a [struct] or [union].
When the operand is [mutable], the field expression is also mutable.

The syntax for a field expression is an expression, called the container operand*, then a `.`, and finally an [identifier].
The syntax for a field expression is an expression, called the *container operand*, then a `.`, and finally an [identifier].
Field expressions cannot be followed by a parenthetical comma-separated list of expressions, as that is instead parsed as a [method call expression].
That is, they cannot be the function operand of a [call expression].

Expand Down