apple / apple/swift-async-algorithms
Could we make AsyncShareSequence public?
- Dominant language
- Swift
- Stars
- 3.7k
- Forks
- 226
- Avg merge
- 10d 3h
- Merged PRs (30d)
- 1
Description
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>`. 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](https://forums.swift.org/t/storing-a-share-d-asyncsequence-and-conforming-to-a-protocol/84524).
Related to PR #412
Contributor guide
Research direction
Start by inspecting the implementation and public return type of `.shared()`, then read related PR #412 and the linked Swift Forums discussion for the proposed approaches. Done means the share sequence type can be named and stored by clients while preserving access to standard AsyncSequence methods and package methods such as `.debounce()`.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- api, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100