The current design hides .shared() return type behind opaque, which creates terrible developer experience when you need to store shared publishers as class or actor variables. Yes, we can wrap them into existential any but that will ruin the entire pipeline! Because both standard AsyncSequence methods like .map() as well as methods from this package like .debounce() can't be called on existential! Going with opaque types isn't an option because class needs to know it's types on init, and AsyncShareSequence is internal, so we can't specify it. I'm trying to convert my code from Combine to Concurrency and I struggle because of this limitations!
So, returning to my proposal. In the asyncSequence.map() we cold save the day specifying the type of the variable exactly: AsyncMapSequence<AsyncStream<..., Never>>. The concrete type is bulky but it will work. Again, we can't use AsyncShareSequence due to internal access.
The problem and various approaches to is discussed on the forums thread.
Related to PR #412
The current design hides
.shared()return type behind opaque, which creates terrible developer experience when you need to store shared publishers as class or actor variables. Yes, we can wrap them into existentialanybut that will ruin the entire pipeline! Because both standard AsyncSequence methods like.map()as well as methods from this package like.debounce()can't be called on existential! Going with opaque types isn't an option because class needs to know it's types on init, andAsyncShareSequenceis internal, so we can't specify it. I'm trying to convert my code from Combine to Concurrency and I struggle because of this limitations!So, returning to my proposal. In the
asyncSequence.map()we cold save the day specifying the type of the variable exactly:AsyncMapSequence<AsyncStream<..., Never>>. The concrete type is bulky but it will work. Again, we can't useAsyncShareSequencedue to internal access.The problem and various approaches to is discussed on the forums thread.
Related to PR #412