Iterator Creation in the "type erasing" Async[Throwing]Stream Helpers

[rdsquared09]

This is a question mostly for my own edification, so thanks in advance to anyone who has time to chime in! Looking at the code for the helpers which can erase any AsyncSequence to an AsyncStream or AsyncThrowingStream, I see that the iterator is not created until the first time the unfolding closure is called. There was also a Lock introduced here recently, to fix some potential concurrency issue. Rather than capturing the iterator as an optional variable and assigning it on the first invocation of next(), I was wondering if there was any inherent problem with calling makeAsyncIterator() immediately, and capturing that in the closure? Is there some issue there with, perhaps, the iterator being leaked if it's created but the sequence is never actually iterated? Or, maybe some concurrency safety issue? Or, is it just more semantically "correct" to only create the iterator once the sequence is actually being consumed? In short, would this also "work":

  public init<S: AsyncSequence>(_ sequence: S) where S.Element == Element {
    var iterator = sequence.makeAsyncIterator()
    self.init {
      return try await iterator.next()
    }
  }

rather than this, as it is currently implemented:

  public init<S: AsyncSequence>(_ sequence: S) where S.Element == Element {
    let lock = NSLock()
    var iterator: S.AsyncIterator?
    self.init {
      lock.withLock {
        if iterator == nil {
          iterator = sequence.makeAsyncIterator()
        }
      }
      return try await iterator?.next()
    }
  }

Code reference.

[cwalo]

I asked myself the same thing and landed on the side of "don't create the iterator until it's consumed", but after some poking it seems that taking a lock can cause elements to be skipped if many are sent in quick succession. I went ahead and opened an issue for it because it seems distinct from AsyncPublisher and back-pressure. #19