AsyncLazySequence converts a non-asynchronous sequence into an asynchronous one.
This operation is available for all Sequence types.
let numbers = [1, 2, 3, 4].async
let characters = "abcde".async
This transformation can be useful to test operations specifically available on AsyncSequence but also is useful
to combine with other AsyncSequence types to provide well known sources of data.
The .async property returns an AsyncLazySequence that is generic upon the base Sequence it was constructed from.
extension Sequence {
public var async: AsyncLazySequence<Self> { get }
}
public struct AsyncLazySequence<Base: Sequence>: AsyncSequence {
...
}
extension AsyncLazySequence: Sendable where Base: Sendable { }
extension AsyncLazySequence.Iterator: Sendable where Base.Iterator: Sendable { }
Naming
This property's and type's name match the naming approaches in the Swift standard library. The property is named with a
succinct name in inspiration from .lazy, and the type is named in reference to the lazy behavior of the constructed AsyncSequence.
Effect on API resilience
AsyncLazySequence has a trivial implementation and is marked as @frozen and @inlinable. This removes the ability of this type and functions to be ABI resilient boundaries at the benefit of being highly optimizable.
I'm not really following why name it after .lazy? I get that this is what inspires it, but is this really related enough to imitate the name? Seems not, to me.
Is your objection to the name of the type? or the name of the extension?
The type was named that way since it does make the access to the values lazy; just like .lazy does. However I definitely see the merits of naming it terms of its providence to the synchronous sequence at its heart.
To be honest I don't feel very strongly about the name of the type; just that the extension exists (heck... id be cool with that returning some AsyncSequence<Element> if I could write that...)