feat: Add AsyncSequence.flatMapLatest operator#382
feat: Add AsyncSequence.flatMapLatest operator#382peterfriese wants to merge 9 commits intoapple:mainfrom
Conversation
This introduces a simplified version of the flatMapLatest operator for AsyncSequence, along with a basic unit test. Note that this implementation uses unstructured concurrency and may have race conditions regarding task cancellation.
- Replaces naive implementation with a thread-safe approach using ManagedCriticalState. - Introduces generation tracking to prevent race conditions where cancelled inner sequences could yield stale values. - Adds test_interleaving_race_condition to verify correctness under concurrent load. - Ensures Swift 6 Sendable compliance.
- Replaces AsyncThrowingStream implementation with a custom AsyncSequence, Storage, and StateMachine. - Implements explicit state management using Lock for thread safety. - Handles concurrency between outer and inner sequences robustly. - Ensures correct cancellation propagation and error handling. - Verified with test_interleaving_race_condition.
- Moves AsyncFlatMapLatestSequence.swift to Sources/AsyncAlgorithms/FlatMapLatest/ - Extracts FlatMapLatestStateMachine and FlatMapLatestStorage into their own files. - Aligns project structure with other complex operators like CombineLatest and Debounce.
- Added test_outer_throwing to verify outer sequence error propagation - Added test_inner_throwing to verify inner sequence error propagation - Added test_cancellation to verify proper cancellation handling - Added test_empty_outer to verify empty outer sequence handling - Added test_empty_inner to verify empty inner sequence handling - Fixed test_simple_sequence to be more robust against timing issues
- Changed from synchronous map with throwIf to AsyncThrowingStream - Added delay to ensure proper error propagation timing - Fixes intermittent test failures
- Removed LLM-style thinking comments - Kept only essential, professional explanations - No functional changes, all tests pass
- Added FlatMapLatest.md documentation guide - Authored by Peter Friese - Includes introduction, code samples, and use cases - Covers search-as-you-type, location-based data, and dynamic config examples - Compares with similar operators in ReactiveX and Combine
- Created SAA-00nn proposal for flatMapLatest operator - Includes motivation, detailed design, and examples - Covers implementation strategy with state machine - Compares with ReactiveX switchMap and Combine switchToLatest
phausler
left a comment
There was a problem hiding this comment.
There are more detailed review notes that can be made but these are perhaps the most impactful for the pitch phase.
| self.storage = FlatMapLatestStorage(base: base, transform: transform) | ||
| } | ||
|
|
||
| public func next() async throws -> Element? { |
There was a problem hiding this comment.
couple of notes here that might inform the rest of the potential pitch:
the next method should likely be the typed throws variant (because as it currently stands this algorithm always throws, which is less than ideal if the base components never throw)
that would then make the overload for the old variant of next (the unaddorned non-typed throws version as you have written) would be rethrows not throws
There was a problem hiding this comment.
+1 on using typed throws, thanks for the suggestion! I see you implemented this in PR #395, so I will not change it here for the time being.
There was a problem hiding this comment.
so my pr was just to update things, feel free to merge my branch into yours and continue iterating. the major concerns here are more for the review with regards to the closure throwing or being async etc. I can help out with getting the implementation over the line.
| } | ||
|
|
||
| enum Action { | ||
| case startInnerTask(Inner, generation: Int, previousTask: Task<Void, Never>?, previousContinuation: UnsafeContinuation<Void, Error>?) |
There was a problem hiding this comment.
I would like to potentially have the flatMap and switchToLatest families eventually only be driven by one task, do you think that is something we could transition to from this implementation?
There was a problem hiding this comment.
I tried following the implementation of the other algorithms.
Maybe this is something we can look into once the initial version has been merged?
There was a problem hiding this comment.
yes this could be an optimization later down the road.
This PR introduces the
flatMapLatestoperator forAsyncSequence.What's included:
flatMapLatestoperator: A new operator that transforms elements of an asynchronous sequence into new asynchronous sequences, automatically cancelling previous inner sequences when a new element arrives from the outer sequence.switchToLatest).
Motivation:
The
flatMapLatestoperator addresses the common problem of managing asynchronous operations where only the result of the most recent operation is relevant. This prevents wasted resources from stale operations and ensures users always see up-to-date information, particularly in dynamic user interfaces.This PR is an implementation of #381