Templates have the syntaxes {{ range $x }} {{ range $v := $x }} {{ range $k, $v := $x }}. I suppose this could be tweaked to look more similar:

range v := x {
range k, v := x {
range v := x; err {
range k, v := x; err {

If the name err is already in scope, err is assigned iter.Close(), otherwise it brings a new err variable into scope after the loop.

Adapting io/fs.WalkDir is a little tricky because you need to be able to skip directories, but you could do it by adding an fs.WalkIterator struct with a SkipDir method and Path, DirEntry, Error fields. It shouldn't be a Result iterator because the error is not necessarily final, for example, permission errors diving into a subdirectory.

range e := fs.Walk(fsys, ".") {
    if strings.HasPrefix(e.Path, ".") || (e.Entry.IsDir() && os.IsPermission(e.Error)) {
        e.SkipDir()
    }
    if e.Error != nil {
        break
    }
   doSomething(e.DirEntry)
}

In general, the wrappers to adapt existing standard library iterators to the new method are pretty straightforward to write.

The suggested range syntax is unlike anything else in Go, and I don't understand why. We already have for range. Why not use that same syntax?

Also, FYI, there are a couple of iterator proposals kicking around inside the Go team. I hope that they will be published soon.

We already have for range. Why not use that same syntax?

It is my understanding that the for variable scope issue can't be solved in a backwards compatible way, so it needs some new syntax to indicate "this is the loop where that works as expected." It's also good to signal to readers when the native (fast!) looping will happen versus the method based looping (hopefully not slow, but probably slower since it needs a method call). I'd be happy if there were a for based syntax that could make this distinction clear. Looking forward to seeing new proposals!

I am not sure this syntactic sugar like this is needed. As an example, the bbolt library already has iterators, named cursors. With them you can iterate like this:

cursor := bucket.Cursor()
for k, v:= cursor.First(); k != nil ; k, v := cursor.Next() {...}

That seems easy enough without any extra syntax.

@beoran I'd say First() is superfluous as well: the first position is implicitly set in the function, constructing the iterator. PebbleDB (a database, similar to Bolt/Bbolt) has both First() and Next() methods with semantics similar to the one below, and I have never, ever, found the First() method useful. :-)

I use iterator pattern a lot in my code, and it seems Next[T]() (value T, valid bool) works pretty well for vast majority of use cases. This is also similar to how channel value "iteration" works already.

iter := CustomSet.iterator()
// iter points at first value already here

for next, ok := iter.Next(); ok; next, ok = iter.Next() {
/* do stuff */ 
}

@oakad , yes there are several styles of iterators already possible in Go. So that's why I am doubtful that syntactic sugar is really needed, or, that we have to officially bless one style of iteration on the language.

Built in support for range iteration will be handy, though. It can be defined the same as range for loop was defined in C++: in terms of available method Next (or whatever).

You can always do without a blessed iterator syntax. Why do we have three values for statements and range at all? You can do everything with a while true loop (a zero value for loop in Go). The point is to make it more convenient and to prevent errors due to accidental misuse. In particular the scanner idiom with its final .Err() call is prone to misuse. Introducing a new syntax will make it harder for users to accidentally omit the error check.

That said, I'm less committed to the syntax part of this proposal than the interface part of this proposal. Having a standard interface for iteration means we can start building libraries that consume the standard interfaces, batch elements in slices, deduplicate repeated elements, etc., etc.

@carlmjohnson well, there is a precedent for standard interfaces with the error type. There could probably also be a built in iterator type tho achieve this standardization, without adding any new other language features.

Closing in favor of continuing the discussion at #54245.