You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An _[array] expression_ can be written by enclosing zero or more
14
-
comma-separated expressions of uniform type in square brackets. This produces
15
-
an array containing each of these values in the order they are written.
13
+
An _[array] expression_ can be written by enclosing zero or more comma-separated expressions of uniform type in square brackets.
14
+
This produces an array containing each of these values in the order they are written.
16
15
17
-
Alternatively there can be exactly two expressions inside the brackets,
18
-
separated by a semicolon. The expression after the `;` must have type `usize`
19
-
and be a [constant expression], such as a [literal] or a [constant item]. `[a;
20
-
b]` creates an array containing `b` copies of the value of `a`. If the
21
-
expression after the semicolon has a value greater than 1 then this requires
22
-
that the type of `a` is [`Copy`], or `a` must be a path to a constant item.
16
+
Alternatively there can be exactly two expressions inside the brackets, separated by a semicolon.
17
+
The expression after the `;` must have type `usize` and be a [constant expression], such as a [literal] or a [constant item].
18
+
`[a; b]` creates an array containing `b` copies of the value of `a`.
19
+
If the expression after the semicolon has a value greater than 1 then this requires that the type of `a` is [`Copy`], or `a` must be a path to a constant item.
23
20
24
21
When the repeat expression `a` is a constant item, it is evaluated `b` times.
25
-
If `b` is 0, the constant item is not evaluated at all. For expressions that
26
-
are not a constant item, it is evaluated exactly once, and then the result is
27
-
copied `b` times.
22
+
If `b` is 0, the constant item is not evaluated at all.
23
+
For expressions that are not a constant item, it is evaluated exactly once, and then the result is copied `b` times.
28
24
29
25
<divclass="warning">
30
26
31
-
Warning: In the case where `b` is 0, and `a` is a non-constant item, there is
32
-
currently a bug in `rustc` where the value `a` is evaluated but not dropped,
Warning: In the case where `b` is 0, and `a` is a non-constant item, there is currently a bug in `rustc` where the value `a` is evaluated but not dropped, thus causing a leak.
28
+
See [issue #74836](https://github.com/rust-lang/rust/issues/74836).
[Inner attributes] are allowed directly after the opening bracket of an array
51
-
expression in the same expression contexts as [attributes on block
52
-
expressions].
44
+
[Inner attributes] are allowed directly after the opening bracket of an array expression in the same expression contexts as [attributes on block expressions].
53
45
54
46
## Array and slice indexing expressions
55
47
56
48
> **<sup>Syntax</sup>**\
57
49
> _IndexExpression_ :\
58
50
> [_Expression_]`[`[_Expression_]`]`
59
51
60
-
[Array] and [slice]-typed expressions can be indexed by writing a
61
-
square-bracket-enclosed expression of type `usize` (the index) after them.
52
+
[Array] and [slice]-typed expressions can be indexed by writing a square-bracket-enclosed expression of type `usize` (the index) after them.
62
53
When the array is mutable, the resulting [memory location] can be assigned to.
63
54
64
-
For other types an index expression `a[b]` is equivalent to
65
-
`*std::ops::Index::index(&a, b)`, or
66
-
`*std::ops::IndexMut::index_mut(&mut a, b)` in a mutable place expression
67
-
context. Just as with methods, Rust will also insert dereference operations on
68
-
`a` repeatedly to find an implementation.
55
+
For other types an index expression `a[b]` is equivalent to `*std::ops::Index::index(&a, b)`, or `*std::ops::IndexMut::index_mut(&mut a, b)` in a mutable place expression context.
56
+
Just as with methods, Rust will also insert dereference operations on `a` repeatedly to find an implementation.
69
57
70
-
Indices are zero-based for arrays and slices. Array access is a [constant
71
-
expression], so bounds can be checked at compile-time with a constant index
72
-
value. Otherwise a check will be performed at run-time that will put the thread
73
-
in a _panicked state_ if it fails.
58
+
Indices are zero-based for arrays and slices.
59
+
Array access is a [constant expression], so bounds can be checked at compile-time with a constant index value.
60
+
Otherwise a check will be performed at run-time that will put the thread in a _panicked state_ if it fails.
74
61
75
62
```rust,should_panic
76
63
// lint is deny by default.
@@ -90,8 +77,7 @@ let arr = ["a", "b"];
90
77
arr[10]; // warning: index out of bounds
91
78
```
92
79
93
-
The array index expression can be implemented for types other than arrays and slices
94
-
by implementing the [Index] and [IndexMut] traits.
80
+
The array index expression can be implemented for types other than arrays and slices by implementing the [Index] and [IndexMut] traits.
Copy file name to clipboardExpand all lines: src/expressions/await-expr.md
+12-25
Original file line number
Diff line number
Diff line change
@@ -4,24 +4,17 @@
4
4
> _AwaitExpression_ :\
5
5
> [_Expression_]`.``await`
6
6
7
-
Await expressions are legal only within an [async context], like an
8
-
[`async fn`] or an [`async` block]. They operate on a [future]. Their effect
9
-
is to suspend the current computation until the given future is ready
10
-
to produce a value.
7
+
Await expressions are legal only within an [async context], like an [`async fn`] or an [`async` block].
8
+
They operate on a [future].
9
+
Their effect is to suspend the current computation until the given future is ready to produce a value.
11
10
12
11
More specifically, an `<expr>.await` expression has the following effect.
13
12
14
13
1. Evaluate `<expr>` to a [future]`tmp`;
15
14
2. Pin `tmp` using [`Pin::new_unchecked`];
16
-
3. This pinned future is then polled by calling the [`Future::poll`] method and
17
-
passing it the current [task context](#task-context);
18
-
3. If the call to `poll` returns [`Poll::Pending`], then the future
19
-
returns `Poll::Pending`, suspending its state so that, when the
20
-
surrounding async context is re-polled, execution returns to step
21
-
2;
22
-
4. Otherwise the call to `poll` must have returned [`Poll::Ready`], in which case the
23
-
value contained in the [`Poll::Ready`] variant is used as the result
24
-
of the `await` expression itself.
15
+
3. This pinned future is then polled by calling the [`Future::poll`] method and passing it the current [task context](#task-context);
16
+
3. If the call to `poll` returns [`Poll::Pending`], then the future returns `Poll::Pending`, suspending its state so that, when the surrounding async context is re-polled,execution returns to step 2;
17
+
4. Otherwise the call to `poll` must have returned [`Poll::Ready`], in which case the value contained in the [`Poll::Ready`] variant is used as the result of the `await` expression itself.
A *block expression*, or *block*, is a control flow expression and anonymous
16
-
namespace scope for items and variable declarations. As a control flow
17
-
expression, a block sequentially executes its component non-item declaration
18
-
statements and then its final optional expression. As an anonymous namespace
19
-
scope, item declarations are only in scope inside the block itself and variables
20
-
declared by `let` statements are in scope from the next statement until the end
21
-
of the block.
22
-
23
-
Blocks are written as `{`, then any [inner attributes], then [statements],
24
-
then an optional expression, and finally a `}`. Statements are usually required
25
-
to be followed by a semicolon, with two exceptions. Item declaration statements do
26
-
not need to be followed by a semicolon. Expression statements usually require
27
-
a following semicolon except if its outer expression is a flow control
28
-
expression. Furthermore, extra semicolons between statements are allowed, but
29
-
these semicolons do not affect semantics.
30
-
31
-
When evaluating a block expression, each statement, except for item declaration
32
-
statements, is executed sequentially. Then the final expression is executed,
33
-
if given.
34
-
35
-
The type of a block is the type of the final expression, or `()` if the final
36
-
expression is omitted.
15
+
A *block expression*, or *block*, is a control flow expression and anonymous namespace scope for items and variable declarations.
16
+
As a control flow expression, a block sequentially executes its component non-item declaration statements and then its final optional expression.
17
+
As an anonymous namespace scope, item declarations are only in scope inside the block itself and variables declared by `let` statements are in scope from the next statement until the end of the block.
18
+
19
+
Blocks are written as `{`, then any [inner attributes], then [statements], then an optional expression, and finally a `}`.
20
+
Statements are usually required to be followed by a semicolon, with two exceptions.
21
+
Item declaration statements do not need to be followed by a semicolon.
22
+
Expression statements usually require a following semicolon except if its outer expression is a flow control expression.
23
+
Furthermore, extra semicolons between statements are allowed, but these semicolons do not affect semantics.
24
+
25
+
When evaluating a block expression, each statement, except for item declaration statements, is executed sequentially.
26
+
Then the final expression is executed, if given.
27
+
28
+
The type of a block is the type of the final expression, or `()` if the final expression is omitted.
37
29
38
30
```rust
39
31
# fnfn_call() {}
@@ -49,14 +41,11 @@ let five: i32 = {
49
41
assert_eq!(5, five);
50
42
```
51
43
52
-
> Note: As a control flow expression, if a block expression is the outer
53
-
> expression of an expression statement, the expected type is `()` unless it
54
-
> is followed immediately by a semicolon.
44
+
> Note: As a control flow expression, if a block expression is the outer expression of an expression statement, the expected type is `()` unless it is followed immediately by a semicolon.
55
45
56
-
Blocks are always [value expressions] and evaluate the last expression in
57
-
value expression context. This can be used to force moving a value if really
58
-
needed. For example, the following example fails on the call to `consume_self`
59
-
because the struct was moved out of `s` in the block expression.
46
+
Blocks are always [value expressions] and evaluate the last expression in value expression context.
47
+
This can be used to force moving a value if really needed.
48
+
For example, the following example fails on the call to `consume_self` because the struct was moved out of `s` in the block expression.
An *async block* is a variant of a block expression which evaluates to
87
-
a *future*. The final expression of the block, if present, determines
88
-
the result value of the future.
75
+
An *async block* is a variant of a block expression which evaluates to a *future*.
76
+
The final expression of the block, if present, determines the result value of the future.
89
77
90
78
Executing an async block is similar to executing a closure expression:
91
79
its immediate effect is to produce and return an anonymous type.
92
-
Whereas closures return a type that implements one or more of the
93
-
[`std::ops::Fn`] traits, however, the type returned for an async block
94
-
implements the [`std::future::Future`] trait. The actual data format for
95
-
this type is unspecified.
80
+
Whereas closures return a type that implements one or more of the [`std::ops::Fn`] traits, however, the type returned for an async block implements the [`std::future::Future`] trait.
81
+
The actual data format for this type is unspecified.
96
82
97
-
> **Note:** The future type that rustc generates is roughly equivalent
98
-
> to an enum with one variant per `await` point, where each variant
99
-
> stores the data needed to resume from its corresponding point.
83
+
> **Note:** The future type that rustc generates is roughly equivalent to an enum with one variant per `await` point, where each variant stores the data needed to resume from its corresponding point.
100
84
101
85
> **Edition differences**: Async blocks are only available beginning with Rust 2018.
102
86
@@ -105,37 +89,30 @@ this type is unspecified.
105
89
106
90
### Capture modes
107
91
108
-
Async blocks capture variables from their environment using the same
109
-
[capture modes] as closures. Like closures, when written `async {
110
-
.. }` the capture mode for each variable will be inferred from the
111
-
content of the block. `async move { .. }` blocks however will move all
112
-
referenced variables into the resulting future.
92
+
Async blocks capture variables from their environment using the same [capture modes] as closures.
93
+
Like closures, when written `async { .. }` the capture mode for each variable will be inferred from the content of the block.
94
+
`async move { .. }` blocks however will move all referenced variables into the resulting future.
0 commit comments