SE-0304 (3rd review): Structured Concurrency

[Douglas_Gregor]

@Chris_Lattner3

Async isn't a technically correct word for this operation. The fundamental concept of a async {} child computation or a group.async {} child computation is happens independently and typically in parallel with the current task. However, the word async in the Swift language means "potentially suspends". It does NOT mean "happens concurrently". Conflating these two is a huge problem to me, and I think this will make it much more difficult to teach and learn Swift concurrency.

This issue is also raised in the async let thread discussion,

Yes, and there's some rationale over in that thread about centralizing around async for structured concurrency. Yes, async is an adjective/adverb in English, but Dispatch has set a very strong precedent for using async to initiate new asynchronous work.

@Chris_Lattner3

Version 3 of the proposal continues to use this verb pervasively to explain itself, e.g.:

group.async spawns a child task in the task group to execute the given operation function concurrently.

We can certainly clean this up.

@Chris_Lattner3

Per the above point, this modeling:

struct Task<Success: Sendable, Failure: Error>

Seems wrong. In generality, a task can return multiple different results that have different lifetimes (consider a Task talking to a name server and a computation server independently) and tying their lifetime together seem unnecessary and limiting. It seems better to decouple "spawning" the task from "constructing the object", which allows providing more expressive APIs without sacrificing ease of use.

A task has a single starting point and returns a single value, which might be a value or a thrown error. Any asynchronous calls the task does along the way don't create new tasks, they're just part of the same task.

@Chris_Lattner3

Agreeing with the discussion upthread, the design of the sleep API seems like it would benefit from further discussion, crosscuts actors, seems like it could be split out to a subsequent library discussion.

It could be separated out, but it's only worthwhile if we think there's going to be significant revision. Doing sleep really well requires a type to describe time properly, which we don't yet have and is a big undertaking in and of itself. Yet Task.sleep is an important operation, hence my desire to get it the slightly-uglier name Task.sleep(nanoseconds:) and leave the time-type design (and nicer name Task.sleep(_:) for later.

Doug