<div dir="auto">Well, convenient or not, closing is necessary. How else can a generator tell the consumer that no more values are forthcoming?<div dir="auto"><br></div><div dir="auto">Ditto for closing the channel by the consumer. Barring advanced cases with sharing the generator, you can have try-with-resources take care of closing things for you.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 Jul 2023, 11:18 Attila Kelemen, <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer">oleksandr.otenko@gmail.com</a>> ezt írta (időpont: 2023. júl. 3., H, 11:41):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">It should really be channels, not queues. So that either end can close it. That can also solve the problem that you raise about generators being stuck in the scheduler forever. </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div></blockquote><div><br></div><div>That is only enough if you can "close" the iterator (which is of course also a common use case), but in many cases you just want a normal `Iterator` which doesn't need to be closed. In that case, it would be rude to force the client code to close the iterator out of convenience of the implementation (since in that case you wouldn't need it, if you implemented it normally).</div></div></div>
</blockquote></div>