Skip to content

Commit 294b80d

Browse files
committed
Ch. 17: fix some wording issues
1 parent fb46a07 commit 294b80d

File tree

1 file changed

+6
-7
lines changed

1 file changed

+6
-7
lines changed

src/ch17-04-streams.md

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,12 @@ The async `recv` method produces a sequence of items over time. This is an
77
instance of a much more general pattern, often called a *stream*.
88

99
A sequence of items is something we’ve seen before, when we looked at the
10-
`Iterator` trait in Chapter 13, but there are two differences between iterators
11-
and the async channel receiver. The first difference is the element of time:
12-
iterators are synchronous, while the channel receiver is asynchronous. The
13-
second difference is the API. When working directly with an `Iterator`, we call
14-
its synchronous `next` method. With the `trpl::Receiver` stream in particular,
15-
we called an asynchronous `recv` method instead, but these APIs otherwise feel
16-
very similar.
10+
`Iterator` trait in Chapter 13. There are two differences between iterators and
11+
the async channel receiver, though. The first is the element of time: iterators
12+
are synchronous, while the channel receiver is asynchronous. The second is the
13+
API. When working directly with an `Iterator`, we call its synchronous `next`
14+
method. With the `trpl::Receiver` stream in particular, we called an
15+
asynchronous `recv` method instead. These APIs otherwise feel very similar.
1716

1817
That similarity isn’t a coincidence. A stream is similar to an asynchronous
1918
form of iteration. Whereas the `trpl::Receiver` specifically waits to receive

0 commit comments

Comments
 (0)