-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Go 2: iterators #40605
Comments
I think it needs to be spelled out what this means. How can Please give some full examples how usage would look like. What does an iterator on a channel do? How do iterators deal with the slice or maps being modified (also in the number of entries)? Would e.g. To change the signature of next with generics would be backwards incomaptible. It seems it would be good to see how generics will turn out first. Using interface{} values is also very cumbersome as it will require type assertions in the calling code of next. Its also good to think about implementation. Using all these interfaces will cause a lot of allocations and performance impact. |
Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change. |
The generics proposal will enable writing your own iterator interface outside of the stdlib. type Iterator[type T] interface {
Next() bool
Value() T
} This gives you everything except the for x := range it {
fmt.Println(x)
}
// vs
for it.Next() {
fmt.Println(it.Value())
} |
To get an usable and convenient version of
Further,we can add simple lambda expression, describe at #21498. Enum for Option, describe at #19412. |
And any type implement Iterator should be passed to for-loop statement. |
Why don't you try to implement iterators using channels package main
import "fmt"
func main() {
for i := range iterator() {
if i > 5 { // You can exit at any time
break
}
fmt.Println(i)
}
}
func iterator() <-chan int {
ch := make(chan int)
go func(ch chan int) {
defer close(ch)
for i := 0; i < 10; i++ {
ch <- i
}
}(ch)
return ch
} |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
@elissa2333 no, you may have a goroutine leak because this example expects that ALL values will be read from the channel, and only then it will close. the problem with this example is that we cannot find out whether someone is reading from the channel or not (btw, it’s a matter of one pr! implementation of this functionality is way easier that you think), and if no one reads from the channel, so the iterator goroutine will simply be blocked! so this is far from the best option (at the time of this writing) |
This proposal is for the addition of a new builtin type,
iterator
, and a new package,iter
:Why
builtin iterator type
This follows a similar reason as to why
error
is a single method interface and not a struct because it allows any implementation to provide the desired behaviour. The behaviour then comes from the definition of an iterator: a producer of items; hence, the single method,Next
. A direct benefit (all be it difficult to document) is that existing builtin types that are iterable can automatically implement theiterator
interface. Thus no wrapper types would have to be created to accommodate the use of, for example,[]int
in a function which looks like thisfunc sum(nums iterator) int
.package iter
Again much like
iterator
followserror
,iter
follows theerrors
package in the sense that its purpose is to provide utilities for working with iterators. I won't go in to everything that can be built on top of the basiciterator
interface because a quick google search can bring you up to speed on some very common methods like map, reduce, filter, etc. The main reason for including this package is to provide all users with a consistent and convenient package for simplifying their work with iterators.Some Thoughts
iterator
actually look likeNext() (interface{}, error)
where no more items would be identified withio.EOF
or possiblyiter.EOI
.Next() (item T, more bool)
For reference, this proposal has been heavily influenced by Rust's implementation of iterators.
The text was updated successfully, but these errors were encountered: