Roadmap

Related Projects Swift Async Algorithms
#1

Hi everyone,

Thank you to everyone for the great feedback we've had so far on Swift Async Algorithms! Now that you've all had a few days to check out what is in the repo to get us started, I'd like to talk about our roadmap for the project.

For the initial announcement, we've created a 0.0.1 tag. This tag builds with the released version of the Swift 5.6 compiler, but it can't include the full set of API we'd like for a 1.0 source stable release.

First, many functions require the under-development version of the compiler with Clock, Instant, Duration. The main branch has those functions at this time.

Second, we'd like to have an opportunity to review all of the proposed public API of the package with the community. The team has spent quite a bit of time working on the naming, shape, and functionality so far - but there's always room for improvement. Our 1.0 release must have an API that we're happy to support in the long term.

With that in mind, the high level plan is to focus on working towards a 1.0 release of the package, aligned approximately with the release of the Swift compiler. That way, when the Swift concurrency library support for Clock is available, this package will be available right alongside it.

In order to get there, we will focus on the following areas in the near term:

  1. Reviews of currently proposed API in the package, here on the forums. We're hoping to do these in a relatively lightweight fashion.

  2. Narrow scoping of additional algorithms. This isn't a value judgement on if new APIs are useful or not. We just need to make sure we have a rock solid foundation for additive changes in post 1.0 releases.

  3. Expanding test coverage, especially in response to bug reports from early adopters. Oh, and finding some early adopters.

The guides section of the repository is intended to be our starting point for reviews about each algorithm. We'll probably tackle a few of these per week by making a post about one of the guides and focusing discussion in individual threads.

If you're looking for a way to help, here are some areas that we could really use it:

  • Download the package, especially if you're comfortable using main and the nightly Swift compiler, and try to use these functions in real scenarios.

  • Additional unit tests, primarily corner cases or completing coverage.

  • We could also use some help setting up and running our API reviews. This is a bit more of a project management challenge than a technical one, but it's just as important!

I'm really looking forward to continuing the work with this package with the community. Thanks again!

31 Likes
Swift Async Algorithms Proposal: Zip
#2

The guides look like a great starting point but there seems to be some consistencies around usage examples. I think it would be worth striving to have at least one example of each algorithm in each guide to reduce the barrier to entry. Some of these are only going to have usage once in a blue moon for some people, so it would be good to have a solid reference to refer back to.

Can't wait to find some time to have a play with this properly.

2 Likes
#3

Absolutely! The guides are certainly something we welcome contributions on. I expect as we find out more about how these are used we can expand the examples, add clarifications, and so on.

#4

When Swift Algorithms was introduced, it was suggested that the purpose of placing it in a separate package was to allow iteration and stabilization to happen without needing every change to go through the Evolution process, and that once it had stabilized, the goal was to eventually pull it into the standard library directly.

Is the same true of AsyncAlgorithms? Is the hope that eventually these algorithms will be part of the standard library?

#5

It's a bit of a combination of both.

We think there are some things developed in Async Algorithms that should be in the standard library (or _Concurrency). The two big ones are Task.select and the initializers for RangeReplaceableCollection which await collection of AsyncSequence elements.

There are some APIs which are a bit of a grey area. zip is certainly in this category, because its Sequence equivalent is in the standard library.

The rest, though, I think are fine to remain in this package. Some of the APIs we will want to add here have use cases that are a lot more narrow than the majority of standard library API.

Keeping things in a package form also allows the community to iterate on it much more quickly. I suspect that most, if not all, of the package will not require language changes (after 5.7), so we can tag new releases on a schedule that makes sense for the package.

4 Likes
#6

What about the minimal required OS versions? I'd love to adopt some algorithms from this package but it's big blocker if it'd require the latest OS. _Concurrency is already back ported, however I don't know what will happen to the clock related APIs as this package makes some heavy use of those. Swift concurrency is great and such, but it's these common algorithms that are missing to be able to conveniently migrate from reactive frameworks.

1 Like
#7

The package doesn't have any OS dependencies beyond the Swift runtime. I think it should back port as far as the Clock/Duration types can.

3 Likes