"Fork" should fire an exception when trying to consume inner iterables without consuming the container one

Using fork in a for … of loop is highly wasteful because it forces to store all input iterable in memory.

for (const f of fork(inputIterable)) {
  // whatever I do with f here will be cached in the buffer.
  // I can't consume the buffer because I am still able to create a new fork
  // and that will return the items from the beginning
}

The sensible way to use fork is using destructuring:

const [f1, f2] =  fork(inputIterable)

For this reason I think it would be better to forbid to consume the forked iterables when the original iterable is still able to emit new “clones”.

for (const f of fork(inputIterable)) {
  f[Symbol.iterator]().next() // Error! You can't consume the forked iterable while you can still emit new iterables
}

[conartist6]

I’m against this restriction. I considered it as a design option when I wrote my implementation (and voiced that possibility). I guess I hadn’t fully decided, just put the decision off for later.

But let’s look at the code you’re afraid of:

for (const f of fork(inputIterable)) {
  // ...
}

I don’t think this code is really any cause for worry. First, the code is an infinite loop. If there’s a break statement then we get to do our cleanup. If there’s no break statement, then literally the whole rest of the program must be about this iterable, in which case the cache hardly seems like a leak or waste of memory.

I’d argue that you’re also confusing our design intentions a bit. We put in the ability to discard unused cache items as an optimization for a specific use case, when the forks were ultimately going to be reintegrated item by item with zip, merge, or collate. The other use cause, however, where the user consumes some or all of each fork in sequence, is also perfectly valid and probably common. We don’t need to fear that our optimization won’t apply there, we just know that it wasn’t meant to, because with that access pattern it doesn’t really matter if we can or can’t make more forks. If we can’t make more forks, there must be some number n of forks that we made. With sequential access the cache won’t be cleaned up at all until we’re already iterating over the nth fork anyway, which is not much of an optimization.

[conartist6]

Yeah we should certainly express in documentation that there is reason to consider using Array.from() or toArray instead of fork, and that you need to be quite careful it you’re using a fork around infinite iterables