Storing a `.share()`d AsyncSequence and conforming to a protocol

[vanvoorden (Rick van Voorden)]

@pyrtsa

I think this is important feedback on the current design of share(). I, too, don't understand why the return type had to be hidden like that.

Could @Philippe_Hausler shed some light on the current choice? Why not make the return type concrete (... -> AsyncShareSequence<Base>) and public?

I had a similar question on another pitch:

[AsyncAlgorithms] FlatMapLatest algorithm

I'm wondering why we should prefer an opaque some return value here on these. From what I can tell so far Standard Library APIs on AsyncSequence like map and compactMap return public concrete types: AsyncMapSequence and AsyncCompactMapSequence. And AsyncAlgorithms APIs on AsyncSequence like zip and combineLatest also return public types: AsyncZip2Sequence and AsyncCombineLatest3Sequence. I'm a fan of opaque return values and don't mean to block that… but I'm wondering if there was a little mor…

It sounds like in the era before opaque values and primary associated types the choice to return concrete values was out of necessity. But now that primary associated types are available it sounds like the general preference is to prefer opaque.