Skip to content

Commit 2d6cd58

Browse files
committed
Clarify the interplay of Stream and Enum
This is based on trying to clarify/make more obvious a missunderstanding I held until ~yesterday. Namely I thought that calling an `Enum` function on a stream would result in the equivalent of `Enum.to_list` and hence all stream benefits would be forfeit. Yes, it should be clear seeing `Enum.take` work that this isn't the case, but it's not always so easy. This turned out wrong as @benwilson512 pointed out eloquently here: https://elixirforum.com/t/why-is-stream-reduce-while-missing/34422/2 Not sure if this is the best place or way to highlight this in the docs, but I thought I'd give it a shot. One could argue that this documentation belongs in the `Enum` module, but for `Stream` documentation that module is the primary source - plus it's more about `Stream`s implementation of `Enumerable`.
1 parent bb028b9 commit 2d6cd58

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

lib/elixir/lib/stream.ex

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -31,8 +31,13 @@ defmodule Stream do
3131
Due to their laziness, streams are useful when working with large
3232
(or even infinite) collections. When chaining many operations with `Enum`,
3333
intermediate lists are created, while `Stream` creates a recipe of
34-
computations that are executed at a later moment. Let's see another
35-
example:
34+
computations that are executed at a later moment.
35+
Notably, the issue with using `Enum` in this context is with the
36+
intermediate lists that are created as their result. An `Enum` function
37+
used on a stream will still process the elements one by one as they are
38+
emitted by the stream.
39+
40+
Let's see another example:
3641
3742
1..3
3843
|> Enum.map(&IO.inspect(&1))

0 commit comments

Comments
 (0)