Swift Async Algorithms Proposal: AsyncDeferredSequence

[tcldr]

@FranzBusch

Thanks for opening this proposal!

No problem! Happy to contribute in some small way.

@FranzBusch

I think I understand why you want this e.g. wrapping current closure based APIs that should only be lazily called once an iterator has been created.

That's correct. Or, any 'hot' sequence that we may come across in the future which we need to convert to be cold.

@FranzBusch

Instead of having an algorithm that lazily creates an upstream sequence what do you think about having a variant of AsyncStream that only invokes it's closure when the first demand is signalled.

I'm not opposed to that. In fact, it's what I originally proposed in the multicast(_:) thread, but I do wonder if they'll be sequences other than AsyncStream that need to be converted to cold – possibly third-party sequences.

@FranzBusch

Instead of having an algorithm that lazily creates an upstream sequence what do you think about having a variant of AsyncStream that only invokes it's closure when the first demand is signalled.

I think this would be nice, but I don't think it solves the original inspiration for this problem, which we thrash about a little in the multicast(_:) thread. Essentially, multicast(_:) needs someway of restarting its source sequence. If that's an AsyncStream, it needs to be an AsyncStream which invokes its closure for each successive consumer.

I'm not opposed to this solution at all, but I do wonder if a generalised deferred(_:) will be useful for converting other hot sequences people may come across.