> > This will allow us to make streams not support negative integer access by > default. If you have a stream you want that for, you would wrap it in a new > struct and implement Enumerable for it, instructing the protocol callback > on how to meaningfully handle that case. >
The issue with this is that you break a bunch of valid use cases. For example, the example below is actually finite: [1, 2, 3] |> Stream.filter(fn x -> x >= 2 end) But if you say that all streams no longer support negative integer access, you just broke it. This example is also finite: [1, 2, 3] |> Stream.flat_map(fn x -> [x] end) But this next example is not necessarily finite, it depends on the implementation of some_fun: [1, 2, 3] |> Stream.flat_map(some_fun) Other streams, such as Stream.unfold/1, requires us solving the halting problem. That's why I said we need to either choose by allowing maybe infinite streams in some cases or by refusing finite streams in some cases. The former reduces the quality of the guarantees we are able to offer. And the latter is backwards incompatible, so that's a no-go. I think it would be highly detrimental to not be able to perform an index access or an aggregation on Stream.filter or even Stream.flat_map. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JbOdnvUxir%2BqZ4VoV7U%2Be2jnJahc1FD%2B5RAhrLGt7YAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
