lardieri
commented
2 years ago And on the iOS side, we're still building for iOS 9.0 😮
The value would come from allowing clients to access the data in the first several rows while the last several rows are still loading and parsing. But that means using something more sophisticated than a simple array to hold the rows. We would need to implement a repeating callback (probably a delegate as opposed to a closure) to push newly-processed rows to the client, as well as a heuristic for chunking (% of file? every X milliseconds? every 100 rows unless the file has < 500 rows?)
Otherwise, as you said, it's probably easier to let the client make its own background queue. Especially as loading the CSV is almost certainly just the first step: the client probably also has to map the rows into an array of structs or objects, and would want to use the background queue for that as well.
DivineDominion
With Swift's structured concurrency being a thing, it might pay off to provide an
asyncCSV loader that would load in a background Task.All of my apps support macOS 10.12+ so I never used async/await in them. I'd personally like to not break compatibility with my apps :) Offering a closure-based API that is dispatch-able on a BG queue, and easily wrappable in a Task Continuation, would probably be a better first step.
Then again -- users can add wrappers like this themselves. So I'm not sure if we should actually offer something like this in the SwiftCSV library.
A feature like this should offer additional value and not just address latest language trends.