On Wed, Feb 26, 2025 at 2:18 AM Nuno Cruces <ncru...@gmail.com> wrote: > > On Tuesday 25 February 2025 at 18:15:40 UTC Ian Lance Taylor wrote: > > I think what you're presenting is an argument for > > package iter > > // Push returns an iterator, a yield function, and a stop function. > // The iterator will return all the values passed to the yield function. > // The iterator will stop when the stop function is called. > // This provides a way to flexibly convert a sequence of values into a Seq. > func Push[E any]() (seq iter.Seq[E], yield func(E), stop func()) > > > I haven't been able to make this interface work to hide the goroutine logic > from the caller (which IMO is most of the point). > > I may be missing something but ISTM that for this to work (and when > implemented with channels) the caller of seq(yield) needs to run in its own > goroutine. > So, if we return seq(yield), we force the caller of Push to then spin a > goroutine to call seq (and it becomes harder to enforce no parallelism).
That's a fair point. I think that the communication between the iterator and the yield/stop function can be done via coroutines, but that doesn't quite fit the current coroutine implementation in the runtime. My concern with your alternative is that it may be fragile. It should be possible for the function to pass the iterator to another goroutine, but it's not clear to me what will happen to the coroutines in that case. With for/range the language inherently constrains what can happen with the coroutines--and the code is still really complicated with all kinds of special cases around panics and passing the yield function around. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUz2A%3DADmHMrDdK-hWnUdaCxHSAbrL46daTRA-1ar%3Db3w%40mail.gmail.com.
