I agree. Simplifying the number of ways to perform iteration is a huge win for readability.
I’ve never seen an advanced use of co routines I would consider readable. A higher level construct is immensely more readable. The blog post I shared goes into the reasons why. A language that doesn’t want exceptions due to flow control concerns should not have coroutines. > On Feb 25, 2025, at 12:15 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Tue, Feb 25, 2025 at 6:17 AM Nuno Cruces <ncru...@gmail.com> wrote: >> >> I wanted a solution that doesn't necessarily involve goroutines and >> channels, for the same reason that iter.Pull was created: because goroutines >> and channels add unnecessary parallelism that has the potential to introduce >> data races, when what is needed is concurrency without parallelism. > > 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()) > > 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/CAOyqgcXamH48NS%2BHeX%2BAjtC4ncoEm49xN66L3b46Wse4qr%2BYsw%40mail.gmail.com. -- 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/18090803-8709-445E-A2A0-EE99C169E326%40ix.netcom.com.
