Итераторы…
TL;DR: в
iter.Seq итератор сам передаёт следующие элементы в код внутри range, а через
yield получает сигнал, продолжать обход. Ошибку можно передавать вторым значением через
Seq2[T, error], но тогда, если она должна дойти до конца цепочки, все промежуточные итераторы тоже должны уметь её принять и передать дальше, даже если она им не нужна (!). Стоит ли оно такой запары?
Вспомним обычный обход:
for i := 0; i < source.Len(); i++ {
process(source.Get(i))
}
Это типичная pull-модель: внешний код сам сначала вытаскивает значение из источника
Get(i), а потом передаёт его в бизнес-логику
process.
Обратный вариант - обход с callback функцией:
source.Scan(func(v Value) bool {
process(v) // принимает то, что будет попадать из цикла ниже
return true
})
func (s *Source) Scan(process func(Value) bool) {
for i := 0; i < s.Len(); i++ {
if !process(s.Get(i)) {
return
}
}
}
Внешний код вызывает
Scan один раз, а дальше уже
Scan достает данные и сам вызывает коллбек
process - в ответ получает
bool и принимает решение об остановке. С точки зрения вызывающего кода это push-модель.
Многострадальные итераторы работают по тому же принципу, только такой callback-обход стандартизирован общим типом
iter.Seq
go
func Numbers(n int) iter.Seq[int] {
return func(yield func(int) bool) {
for i := 0; i < n; i++ {
if !yield(i) {
return
}
}
}
}
Коллбек-механика спрятана внутри range:
go
for v := range Numbers(10) {
// callback логика тут, а вызывает ее код из Numbers
if v == 5 {
break
}
}
Numbers сам вызывает
yield с очередным значением. Код внутри
range получает значение, обрабатывает (в нашем случае сравнивает с 5), и отдает
bool итератору, где последний решает, продолжать ли обход.
С остановкой по инициативе коллбека внутри
range всё ок. Но что, если продолжить обход не может уже сам итератор - например, если чтение следующего значения закончилось ошибкой.
В
Seq[T] передать её некуда. Один из вариантов - вынести ошибку во второе значение:
func Values() iter.Seq2[int, error] {
return func(yield func(int, error) bool) {
for i := 0; i < 10; i++ {
v, err := readValue(i)
if err != nil {
yield(0, err)
return
}
if !yield(v, nil) {
return
}
}
}
}
Тогда ошибка приходит в тот же
range, что и данные:
for v, err := range Values() {
if err != nil {
return err
}
process(v)
}
Для одного итератора это выглядит естественно. Но в композиции с другими итераторами, например c
func Double(seq iter.Seq[int]) iter.Seq[int] {
return func(yield func(int) bool) {
for v := range seq {
if !yield(v * 2) {
return
}
}
}
}
eсли ошибка из
Values должна пройти через
Double до конечного потребителя, то`Double` (который сам упасть не может и которому не нужна ошибка), вынужден перейти на
Seq2[int, error] (иначе у нас просто не скомпилится тк
Double принимает `Seq[int]`) и явно передавать чужую ошибку
Чтобы не разводить зоопарк предложили даже собирать такие ошибки через отдельный хелпер`slices.CollectError` в
#70631
func CollectError[T any](seq iter.Seq2[T, error]) ([]T, error) {
var err error
result := slices.Collect(func(yield func(T) bool) {
for v, e := range seq {
if e != nil {
// записываем первую ошибку
err = e
// завершаем обход
return
}
if !yield(v) {
return
}
}
})
return result, err
}
Просто как кейс стандартизации обработки ошибки через
Seq2[T, error]. Или очередной способ задать себе правила 🙂
Еще нашла
#71901 где решают, какой контракт для итераторов с ошибками стоит считать стандартным. Но мне страшно туда лезть..
#go
