SE-0304: Structured Concurrency

[Lantua]

group as AsyncSequence doesn't feel exactly useful. There's a recent pitch about end-of-iteration behaviour of AsyncSequence. If we ended up adopting this, this means we can do for ... in group only once at the end. If we want to iterate through the group multiple times, we need to fallback to group.nextResult.

What if we use group.currentResults() for AsyncSequence instead? See below.

---

@Lantua

But returning nil upon failure is exactly a Swift pattern... And if we extend any of it's capabilities, it's more likely to be added to Task.handle .

On a more holistic look on spawn vs add, looking at the PR:

• I think it's a shame that we remove back-pressure, it could be useful when scheduling a lot of subtasks. Though it's not necessary since we can achieve it manually:

  for ... in 0..<10 {
    group.spawn(...)
  }
  for result in group {
    // handle `result`
    group.spawn(...)
  }
  

• group.spawn and group.nextResult feels like they're at odd with each other. Task.Spawned exactly identifies one particular handler for one specific spawn, while nextResult anonymizes the origin. If, for example, I can't cancel one particular Spawn because it's already completed, I have no idea which one in the group.nextResult is the corresponding result.