Summary
Add Ordered vs Unordered result ordering control for map-style batch operations.
Goal
Let consumers choose, per call: stable predictable ordering (results[5] ≡ items[5], default) or lower-latency streaming order (Unordered).
Reasoning & Build
Ordered (default)
- Predictability; higher memory cost (results buffered to retain index order).
Unordered (opt-in)
Design Expectations
Ordered is the default; Unordered is clearly opt-in.
- Composes with
MapParallel (chunking ordering) and map APIs.
Acceptance Criteria
Non-Goals
- No reordering semantics beyond index stability / streaming.
Summary
Add
OrderedvsUnorderedresult ordering control for map-style batch operations.Goal
Let consumers choose, per call: stable predictable ordering (
results[5]≡items[5], default) or lower-latency streaming order (Unordered).Reasoning & Build
Ordered(default)Unordered(opt-in)Lower latency ("streaming"); results returned/yielded as soon as they finish.
Snapshot-internal use: DB insert where order is irrelevant.
OrderedandUnorderedmodes surfaced on the relevant batch/map primitives.Unorderedstreams results as they complete (lowest latency).Orderedbuffers to preserve input index mapping.Unit tests for both modes' contract + memory tradeoff note.
Design Expectations
Orderedis the default;Unorderedis clearly opt-in.MapParallel(chunking ordering) and map APIs.Acceptance Criteria
Unorderedpath returns as soon as items finish.Non-Goals