The pattern you describe is used in several stdlib packages (notably bufio.Scanner, which leads to a loop that looks like `for scanner.Scan() { doStuff(scanner.Text()) }`. The only variation from your example is that in the stdlib, `iterator.Continue()` both tests for the end condition and advances the iterator state. With that change, it ends up not much more verbose than the second syntax you suggest.
https://github.com/golang/go/issues/13027 is a past proposal to allow the `range` operation to work on arbitrary types (although it was originally proposed as a narrow enhancement on container/list only). Didn't get very far, but sprinkled in the bug are some of the objections a new proposal would want to address. The big one for me personally is the argument for readability: currently, Go code doesn't contain surprising execution: if there's not a function call, you can reasonably expect that there's no hidden computation happening. Python-style iterators and generators specifically go against that, in that a simple looking range statement might run arbitrarily complex code between loop iterations, rather than just increment a pointer. I think that's the big non-technical question to address, aside from the mechanics of syntax and semantics. - Dave On Sun, Oct 21, 2018 at 5:41 PM Eric Raymond <e...@thyrsus.com> wrote: > I have a real-world case where I need Python style iterators for > performance. It's not good to eager-evaluate an event-list 259K items when > you know that in the typical case you're only going to select two or three > orders of magnitude fewer of them to be passed to a work function. (The > list is of commit events in a version-control repository; the selector > might be something like "commited within 24 hours of time t"). > > There's an obvious, clumsy way to do this by having a factory pass back a > stateful iterator object: > > for iterator := IteratorFactory(selector); iterator.Continue();iterator. > Next(){ > DoSomethingWith(iterator.Value()) > } > > > What one would really like to be able to do, though, is much more concise: > > for i, v := range iteratorFunction() { > DoSomethingWith(i, v) > } > > Before I post an RFE, are there rejected iterator proposals I should read > so I don't waste anyone's time on stale ideas? > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.