I've stumbled upon your repo from this post. It's great to have this lazy iterators for efficient chaining of operations in go!

Since https://github.com/samber/lo is the biggest functional programming library for go, have you considered integrating this into it?

If the parent function returns early, you end up with blocked orphaned go-routines

In each case, you use a go-routine to populate the channel you are ranging over, and as you said, that blocks until the next element is read using the range function. Isn't this problematic if you do error handling in the for loop? Even though it won't block the main thread, wouldn't the go-routine block and stay around forever as long as the main thread runs? If this is a server, then as long as the server is alive? If it serves many requests, you might just keep adding more and more go-routines!

Example:

for item := range Range(10) {
	if item == 2 {
		return
	}
}

The previous example would return without reading the rest of the ints in the channel and thus leave the orphaned go-routine around.

Full example file that demonstrates the orphaned go-routines getting created:

package main

import (
	"fmt"
	"runtime"

	"github.com/lucemhealth/go-common/lucemtelemetry"
)

func main() {
	lucemtelemetry.ConfigureZerologLogger()

	for i := 0; i < 10; i++ {
		fmt.Printf("request number: %d\n", i)
		fmt.Printf("starting number of routines: %d\n", runtime.NumGoroutine())
		doForLoop()
		fmt.Printf("ending number of routines: %d\n", runtime.NumGoroutine())
		fmt.Println()
	}
}

func doForLoop() {
	for item := range Range(10) {
		if item == 2 {
			return
		}
	}
}

func Range(nmax int) chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for index := 0; index < nmax; index++ {
			out <- index
		}
	}()
	return out
}

I have some performance concerns regarding the use of channels as the only way to propagate, but there's not a nice way for you to address that without, like, rewriting the whole thing. So I'll complain about something that's straightforward enough:

currently, your worker interface takes two channels and returns nil. Instead, a worker should be expected to take a context and a receive-only channel, returning a new context and a new receive-only channel. This change would ensure that the responsibility for each channel is clear, error propagation on a pipeline is controlled at each step by the propagator, and the implementor is far less likely to leave a thread hanging in the background, still running.

Unfortunately, I'd still have the doesn't-know-how-to-share-memory issue, so I'd still be using native loops and/or chains of reader/writer interfaces for same-thread iteration.